ClickUp CLI

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.10.0
Disambiguation5/5
Each tool has a distinct purpose with clear resource-action naming (e.g., task_create vs task_get). Over 140 tools are all uniquely disambiguated by their resource and action, avoiding any ambiguity.
Naming Consistency5/5
All tools follow the consistent pattern clickup_<resource>_<action> in snake_case. No mixing of conventions like camelCase or inconsistent verb forms.
Tool Count4/5
143 tools is large but appropriate for a comprehensive CLI covering ClickUp's many features (tasks, docs, chat, goals, time tracking, etc.). While exceeding the typical 3-15 range, the scope justifies the count.
Completeness5/5
The tool surface is extremely complete, covering CRUD for all major resources (tasks, lists, folders, spaces, docs, comments, checklists, chat, goals, tags, webhooks, views, time entries) plus search, sharing, guest management, and workspace info.
Average 4.3/5 across 143 of 143 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 15 of 15 community issues answered or closed in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose side effects (e.g., whether the guest still exists, if they are notified). It only states the action, lacking behavioral details beyond the core operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the purpose without unnecessary words. However, it is not structured with any additional formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of annotations or output schema, the description is minimal. It does not address prerequisites, results, or post-conditions, making it incomplete for a thorough understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no meaningful information beyond the schema's field descriptions ('Guest user ID', 'Task ID'), which are already sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Revoke a guest's access to a task' clearly identifies the action (revoke) and the resource (guest's access to a task). It distinguishes the tool from siblings like clickup_guest_share_task and clickup_guest_unshare_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as clickup_guest_remove or clickup_guest_unshare_list. The context for choosing this tool over others is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It fails to mention what happens when no entry is running (e.g., returns null or error) or any side effects. The minimal description lacks necessary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it sacrifices completeness. It could include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one optional param, no output schema), the description is somewhat complete but lacks details on return behavior when no entry is running. Some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (team_id is documented in the schema). The tool description adds no extra parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('currently running time tracking entry'), which is distinct from sibling tools like clickup_time_get (specific entry) and clickup_time_list (list entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives (e.g., clickup_time_get for a specific entry), nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states 'Move' (mutation) but does not mention permissions, reversibility, side effects (e.g., whether comments/attachments are preserved), or performance implications. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word is meaningful, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no annotations or output schema, the description is minimally adequate. It describes the core operation but omits context like prerequisites (task must exist, list must exist), expected output, and error scenarios. Additional details would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, such as how list_id relates to the original task's location or what happens if team_id is omitted. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a task') and the resource ('to a different list'), with a clarifying parenthetical ('change home list'). This is a specific verb+resource combination that distinguishes it from sibling tools like clickup_list_add_task or clickup_task_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as clickup_list_add_task (adds a task to a list without changing home list) or clickup_task_update (updates task properties). The description lacks any context about preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Create,' implying a write operation. It does not disclose side effects (e.g., template unchanged), required permissions, or what happens if the template doesn't exist. Minimal beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no wasted words. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain what the tool returns or mention prerequisites (e.g., template must exist, access rights). Missing critical context for a creation tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with clear descriptions for all 4 parameters. The tool description adds no extra meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a list from a list template in a folder or space' clearly states the verb (create) and resource (list from template), and distinguishes from siblings like clickup_list_create (create empty list) and clickup_template_apply_folder (apply template to folder).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list template ID is available and a new list is needed, but does not explicitly state when not to use it (e.g., for creating empty lists, use clickup_list_create) or mention the mutual exclusivity of folder_id and space_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states the return format (array of reaction summary objects with emoji, count, users) but does not disclose other behavioral traits such as read-only nature, authentication requirements, rate limits, or potential empty results. Minimal disclosure beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence followed by a short, clear return summary. No redundant information; every word serves a purpose. It is front-loaded with the core action and quickly explains the output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description provides a high-level summary of return fields (emoji, count, users). However, it lacks details about exact field names, error conditions, or behavior when no reactions exist. Adequate but could be more complete, especially for an agent expecting structured output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. The schema already explains message_id and team_id with references to other tools. The description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists emoji reactions on a ClickUp Chat message, grouped by emoji, including count and users. It specifies the resource (message), verb (list), and output structure, distinguishing it from sibling tools like clickup_chat_reaction_add or clickup_chat_reaction_remove. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (listing reactions for a chat message) but does not explicitly state when to use this tool versus alternatives like clickup_chat_reaction_add or clickup_chat_reaction_remove. No when-not-to-use or alternative guidance is provided, so the agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral transparency. It states the mutation ('stop') but omits details about error handling (e.g., if no running entry exists), return value, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information, achieving maximum conciseness while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is minimal. It lacks information about return values or error cases, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (team_id) with a clear description. The tool description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('currently running time tracking entry'), distinguishing it from siblings like clickup_time_start and clickup_time_current.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to stop tracking), but provides no explicit guidance on when not to use it or alternatives. Given the sibling list, the context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'list', which implies a read-only operation, but does not disclose authentication needs, error behavior for invalid workspace IDs, or return format. For a list operation, more detail on output structure would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It is front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but not complete. It does not mention what happens when team_id is omitted (default from config), nor does it describe the return value format (e.g., array of tag objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter, team_id, with clear description). The description adds no new meaning beyond 'for a workspace', which aligns with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all time entry tags for a workspace. It uses a specific verb ('List') and resource ('time entry tags'), and it distinguishes itself from sibling tools like clickup_tag_list (general tags) and clickup_time_add_tags (which adds tags).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (listing time tags for a workspace) but offers no explicit guidance on when to use this tool versus alternatives like clickup_tag_list, which lists all tags regardless of type, or clickup_time_list, which lists time entries. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions coverage of both manual and stopped timers and the return format, but does not disclose pagination, ordering, or default behavior when no filters are provided. The schema's note about a 30-day cap is not repeated in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two informative sentences. The first sentence states purpose and filters; the second adds coverage and return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return format details. It covers filtering options and entry types. However, it lacks mention of default behavior (e.g., what happens when all params omitted) and pagination, which would be helpful for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about optional filtering and coverage, but does not provide additional semantic meaning beyond the schema's detailed parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'historical time tracking entries', and specifies optional filtering. It differentiates from siblings like clickup_time_history by mentioning coverage of both manual and stopped timers, but does not explicitly contrast with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing historical entries with optional filters, but does not provide explicit guidance on when to use this tool over alternatives like clickup_time_history or clickup_time_get, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it 'Fetches' and lists return fields, implying a read-only operation. However, it does not explicitly confirm side-effect-free behavior, auth requirements, or rate limits, leaving some gaps for a simple fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with key purpose, but includes a redundant final sentence 'Returns the time entry object' that echoes the first sentence. Almost excellent but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with clear schema and no output schema, the description adequately lists returned fields and purpose. Could mention error handling or authentication context, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already has descriptions for both parameters (team_id and timer_id) with 100% coverage. The description adds no additional parameter explanation beyond what's in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch the full object for a single time tracking entry' and lists specific fields (user, task, start timestamp, etc.), distinguishing it from siblings like clickup_time_list (listing) and clickup_time_current (current entry).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives like clickup_time_list. The description implies usage for retrieving a single entry by ID, but does not provide when-not-to-use or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the membership distinction but does not disclose authentication requirements, rate limits, or potential errors. The return format is mentioned but not additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. The purpose, scope, and alternative are presented concisely and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers purpose, return format, and differentiation from sibling. It does not mention pagination or filtering, but these are not critical for basic usage. Overall complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions already explain how to obtain channel_id and team_id. The tool description adds no further meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists members who can read and post, with a specific verb and resource. It distinguishes from the sibling tool 'clickup_chat_channel_followers' by clarifying the different access levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool for notification-receivers, guiding the user on which tool to use. However, it does not mention prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States ordering and basic output, but with no annotations, it does not disclose whether it's read-only, pagination behavior, or any side effects. Surficient but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Front-loaded with the main action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description only says 'Returns an array of reply objects' without detailing the structure of those objects. Leaves agent guessing about fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already provide clear guidance on obtaining parameter values. The description does not add extra semantics beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the tool as listing threaded replies to a top-level ClickUp Chat message, with ordering (oldest first) and return type. Distinguishes from sibling clickup_chat_reply_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use the alternative tool (clickup_chat_reply_send) for posting. However, lacks explicit conditions for when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states return type but does not disclose whether operation is idempotent, error handling, or access requirements. For a read operation, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose first, then prerequisite. No extraneous words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers key return fields (content, title, subtitle, parent-page link). Lacks details on error conditions or response format, but sufficient for a straightforward fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds minimal extra meaning beyond schema; mentions 'parent-page link' but that is a return field, not parameter context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Fetch a single page from a ClickUp doc' with details on included content (markdown, title, subtitle, parent-page link). Clearly distinguishes from siblings like clickup_doc_pages and clickup_doc_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite: 'Use clickup_doc_pages to list all pages in a doc first.' Lacks explicit when-not-to-use or alternative tools, but clear context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns an array of page objects with specific fields (id, name, sub_title, parent_page_id, optionally content) and that pages are ordered by tree position. It does not mention rate limits, permissions, or what happens on invalid doc_id, but the core behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly worded sentences. The first states the purpose, the second lists return fields, and the third adds ordering detail. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool without an output schema, the description adequately explains the return format and ordering. However, it lacks details on pagination (if applicable) and error handling. Considering the tool's simplicity, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the tool description adds minimal value beyond the schema. It indirectly references the content parameter by mentioning 'optionally content' in the return format, but does not provide new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'List' and the resource 'pages inside a ClickUp doc'. It also mentions including nested subpages, which distinguishes it from sibling tools like clickup_doc_get_page (single page) or clickup_doc_get (the doc itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it compare with sibling tools such as clickup_doc_get_page, clickup_doc_add_page, or clickup_doc_edit_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes fetching audit history (read operation) but no annotation provided. Does not mention potential side effects, rate limits, or data retention. Adequate but not deep.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and return type. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what is fetched and returned; mentions key fields. Lacks explicit read-only statement but adequate for a simple audit tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Tool description adds no extra parameter detail beyond stating it needs timer_id implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches audit history of time tracking entries, listing specific change types and return format. It distinguishes from siblings like clickup_time_get and clickup_time_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'useful for auditing' but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. No prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the return type (object with shared tasks, lists, folders arrays) and clarifies what 'shared' means. However, it does not mention potential pagination, response size limits, or permission requirements beyond the authenticated user context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences that are concise and well-structured. The first sentence states the purpose, the second adds usage context, and the third describes the return type. There is no fluff, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must compensate. It states the return is an object with arrays, but it does not specify the fields within those arrays (e.g., task names, IDs). More detail on the response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (team_id) with full schema description coverage (100%). The tool description does not add any additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'every task, list, and folder that has been explicitly shared...'. It distinguishes from sibling tools like clickup_list_list, clickup_task_list, etc., which list owned items, by specifying 'from outside their default hierarchy' as a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for discovering items you have access to but don't own.' It implies when to use this tool (for shared items) but does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns a task object and includes many fields, but it does not disclose potential side effects, permission requirements, or rate limits. Since no annotations are provided, the description carries full burden but offers only basic read operation disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but the first sentence is somewhat lengthy by listing many fields. It is well-organized and front-loaded with the core action, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description fairly comprehensively lists the fields returned and directs users on how to obtain the required task ID. However, it could be more explicit about whether all data is always returned or if there are limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (include_subtaks and task_id). The description adds no additional semantic value beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full object of a single ClickUp task, listing many specific fields (name, description, status, etc.), and distinguishes it from sibling tools by directing users to clickup_task_list or clickup_task_search for finding task IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to get a single task) and mentions alternative tools for finding task IDs, though it does not elaborate on other circumstances or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It states the return type (array of template objects) but does not disclose behavioral traits like read-only nature, authorization requirements, or pagination behavior beyond what the schema provides. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. First sentence states purpose, second explains what templates are and links to the apply tool, third specifies return format. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description must explain return values. It does so minimally ('Returns an array of template objects (id, name)'), but lacks details on whether the array is the complete result or paginated, and does not mention other possible fields or metadata. Sufficient for a simple list but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description adds value by explaining the source of team_id ('Obtain from clickup_workspace_list') and clarifying pagination ('Zero-indexed page number... up to 100 templates'), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List the task templates available in a workspace.' It uses a specific verb ('List') and resource ('task templates'), and distinguishes itself from sibling tools by mentioning the apply action and specifying the scope ('in a workspace').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (list templates before applying via clickup_template_apply_task), but it does not explicitly state when to use or when not to use. No alternatives or exclusions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly identifies a read-only operation but omits details like authentication requirements, rate limits, or any potential errors. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of five words, front-loading the core purpose. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple read operation, the description is adequate but does not hint at the return fields (e.g., user ID, email). An AI agent might benefit from knowing what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter info, but baseline for zero-parameter tools is 4 since no additional meaning is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the currently authenticated ClickUp user' clearly states a specific verb ('Get') and resource ('currently authenticated ClickUp user'), distinguishing it from sibling tools like clickup_user_get, which retrieves a specific user by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for retrieving current user identity, but lacks explicit guidance on when to use this tool versus alternatives like clickup_user_get or clickup_auth_check. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully explain behavior. It notes pagination and that the tool lists channels the user can see (implying authorization). However, it does not disclose details like rate limits, required permissions beyond authentication, or how pagination works (e.g., page size, cursor usage). The description adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a clear purpose: stating the operation and providing pagination details, return fields, and an alternative tool. No redundant information, front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the return fields (id, name, visibility, topic, last_message_at) and mentions pagination. It also references a sibling for creation. It does not mention other relevant siblings like get or delete, but the core information is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (both parameters have meaningful descriptions). The tool description does not add new parameter information beyond the schema; it only lists return fields. The schema already explains the parameters well, so the description adds minimal value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all ClickUp Chat channels in a workspace that the authenticated user can see.' It uses a specific verb (list) and resource (chat channels), and distinguishes from siblings like clickup_chat_channel_create (create) and clickup_chat_channel_get (single channel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Uses v3 cursor pagination' implying it's for bulk listing, and explicitly says 'Use clickup_chat_channel_create to create new channels,' guiding when to use an alternative. However, it does not explicitly exclude use cases like retrieving a single channel, which is served by clickup_chat_channel_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency (no-op if already reacted) and success return type (empty object). No annotations provided, so description carries full burden; however, it does not mention authorization requirements or error conditions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, behavior, and return. No fluff; every sentence provides distinct value. Ideal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reaction-add tool, the description covers the core functionality, idempotency, and success response. It lacks mention of error cases (e.g., invalid message_id, permissions) but is still fairly complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The tool description adds no additional parameter semantics beyond what is already in the schema, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add an emoji reaction') and the resource ('ClickUp Chat message'), and includes idempotency behavior that distinguishes it from other reaction actions. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies safe repeated use via 'no-op', it does not explicitly guide when to use this tool versus siblings like clickup_chat_reaction_list or clickup_chat_reaction_remove. Missing context on when this is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full behavioral burden. It explains the net effect (modify fields) and return value (updated checklist object). Does not disclose potential side effects (e.g., notifications, immutability) or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose and actions, second links to siblings and return value. No wasted words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description adequately covers purpose, ID sourcing, and return value. Missing advanced context like rate limits or error handling, but sufficient for a simple update tool with well-documented input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with detailed descriptions. The description adds high-level grouping (three actions) and ID sources, but does not provide new semantic insight beyond the schema. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies a single checklist item, listing specific actions (rename, toggle resolved, change assignee). It distinguishes from sibling tools clickup_checklist_add_item and clickup_checklist_delete_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (modify existing item) and mentions alternatives for create/delete. Implicitly guides on prerequisites by referencing ID sources (clickup_task_get, clickup_member_list). Lacks explicit when-not or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the goal's percent complete is derived automatically and that the tool returns the updated goal object. However, it does not mention permissions, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Clear and front-loaded: the first sentence states the purpose, the second provides critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what fields can be updated, derived behavior of percent complete, and returns the updated object. Lacks details on error handling or prerequisites, but given the tool's simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by listing the fields and linking goal_id to another tool (clickup_goal_list), but does not significantly enhance individual parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool modifies a ClickUp goal's top-level fields (name, description, due date). It also distinguishes itself from updating key results, which is a related sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (top-level fields) vs. when to use clickup_goal_update_kr (progress/ key results). Also mentions that percent complete is derived automatically, guiding the user away from manually setting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the goal's completion percentage auto-recalculates and returns the updated object, but lacks details on reversibility, permissions, or error states. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences well-structured: first sentence states purpose and typical uses, second sentence covers side effect and return value. No extraneous information, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with well-documented parameters, the description covers the core functionality, side effects, and return value. It lacks mention of prerequisites or error handling, but is sufficient given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description adds context about typical uses (progress, rename, unit) but does not significantly enhance parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a key result on a ClickUp goal, with typical use cases like recording progress, renaming, or adjusting unit label. It is distinct from siblings like add/delete KR by specifying 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (updating existing KRs) but does not explicitly contrast with siblings like clickup_goal_add_kr or clickup_goal_delete_kr. It provides enough context for an agent to infer usage, though explicit alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the space uses workspace defaults and returns the created object with its new ID, but does not disclose permissions required, potential duplicate name handling, or any side effects. For a creation tool, the transparency is decent but could mention more about underlying behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, behavior note (defaults and customization), return value. No redundant words. Each sentence adds necessary information. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 100% schema coverage, and no output schema, the description is fairly complete. It specifies the return includes the object with its ID, which is critical. It could mention the team context (already in param) or potential error cases, but for a simple creation tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description does not add meaning beyond what the schema provides (e.g., 'name' as display name, 'private' as boolean). The description's mention of default feature sets is behavioral, not parameter-specific. Since schema already explains parameters well, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new top-level space in a ClickUp workspace' with a specific verb and resource. It distinguishes from sibling tools like clickup_folder_create and clickup_list_create by specifying 'top-level space'. The detail about using workspace defaults further clarifies the tool's specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the new space uses default feature sets and can be customized later, providing context on when to use this tool (for quick creation with defaults). It doesn't explicitly state when not to use it or compare to alternatives, but the guidance about customization implies it's not for fully configured spaces. Adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reports historical data (read-only, since creation) and describes the return format in milliseconds but does not disclose potential side effects, authentication needs, or rate limits. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the purpose and resource, second provides an example and return details. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format (mapping of status names to times in milliseconds). The parameter is well-documented in the schema. It lacks error handling or edge case information but is near-complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description adds no additional meaning beyond what the schema already provides (e.g., the schema already explains how to obtain task_id). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'report' and resource 'how long a task has spent in each status', provides an example, and distinguishes it from sibling tools like clickup_task_get or clickup_task_list which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'Useful for cycle-time analysis', providing clear context for when to use this tool. While it doesn't list exclusions or alternatives, the sibling tools cover distinct operations, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the tool is a read-only list operation with no side effects, but it does not cover error handling, rate limits, or authorization requirements. Given no annotations, the description carries the full burden and provides adequate transparency for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and examples. Every sentence adds value: purpose, examples, and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return array structure (id, name, icon) and connects to task creation. It lacks details on pagination or potential length, but for a simple list tool it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides for the team_id parameter. It simply mirrors the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists custom task types (Custom Items) at the workspace level, giving concrete examples (Bug, Epic, Feature). It distinguishes from sibling tools like clickup_task_create and clickup_task_list by specifying the scope and return value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when users need to know available task types before creating tasks, but it does not explicitly state when to use or not use this tool, nor does it compare with siblings like clickup_task_list or clickup_workspace_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-creation of tags and empty return value, but lacks details on idempotency, error handling, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, side effect, and sibling/reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behaviors well for a tagging mutation tool; could mention error handling but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters with descriptions; description adds no extra semantics beyond reinforcing auto-creation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies tags to time entries, distinguishes from siblings like clickup_time_remove_tags and clickup_time_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use clickup_time_tags to list existing tags, providing an alternative. However, no explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly states a read-only listing operation but does not disclose any behavioral details such as pagination, authentication requirements, or potential data volume. This is adequate for a simple list but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that conveys the purpose without any filler. Every word is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers what the tool does. It could mention the return format (e.g., list of workspace objects with IDs and names), but the current description is sufficient for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the description does not need to add parameter information. It correctly implies no parameters are needed, earning the baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and resource 'workspaces (teams)' with scope 'accessible to the current user', clearly distinguishing it from sibling list tools like clickup_space_list or clickup_folder_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like clickup_workspace_plan or clickup_workspace_seats, nor does it provide any exclusions or prerequisites. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It correctly implies read-only (get) and describes return type, but does not disclose potential rate limits or authentication requirements. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds use-case and return type. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read with one optional parameter, the description explains the return object sufficiently. It does not need more detail given the lack of output schema. Minor omission: no mention of error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good description for team_id. The tool description does not repeat parameter details but adds context about output. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves seat-usage breakdown (member, guest, internal seats) and differentiates from sibling tools like clickup_workspace_list and clickup_workspace_plan by focusing on capacity details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is useful before inviting new users to confirm capacity, providing a clear usage context. However, it does not mention when not to use it or list alternatives, though this is minor given the specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explains key behaviors: requires Enterprise plan, uses cursor pagination, returns array of audit event objects with specific fields. This adds value beyond the schema by disclosing pagination and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, requirement, and behavior. No redundancy, front-loaded with the most important information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a read-only query tool but lacks detail on output structure (e.g., exact fields of audit event objects, pagination details). Without an output schema, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add additional parameter-specific meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query the ClickUp audit log (who did what, when)' with specific filtering capabilities (event type, user, date range). It distinguishes this tool from siblings by naming a unique resource (audit log) not present in other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions Enterprise plan requirement, v3 cursor pagination, and sourcing IDs from other tools (clickup_workspace_list, clickup_member_list). While there is no explicit 'when not to use' guidance, the context around prerequisites is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the checklist starts empty and returns the created object with its id. However, it omits behavioral details like required permissions, error conditions, or side effects beyond creation, which would be expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each contributing essential information: creation action, emptiness and next steps, and return value. It is front-loaded and concise without any redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description helpfully states the return includes the new id. However, it lacks details on error handling, permissions, or output structure beyond the id. For a straightforward creation tool, it is mostly adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both 'name' and 'task_id' already have descriptions. The description adds value by providing examples for 'name' (e.g., 'Launch prep') and sourcing guidance for 'task_id' (from clickup_task_list). This additional context justifies a slight upgrade from baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'checklist (to-do group)' on a ClickUp task. It distinguishes from siblings by mentioning that the checklist starts empty and directs to clickup_checklist_add_item for adding items, making its purpose unique among the many checklist-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use clickup_checklist_add_item to populate the checklist and notes that a task can have multiple checklists, implying no uniqueness constraint. This provides clear guidance on when to use this tool and what to do next.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It correctly indicates that the tool creates a folder and returns the created object including its id. However, it does not mention potential side effects, authorization requirements, rate limits, or error conditions (e.g., duplicate name, non-existent space).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no filler. It front-loads the core action and follows with useful context. While concise, it could benefit from slight restructuring (e.g., separating the usage note), but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple create tool with only two parameters, the description is fairly complete. It covers the purpose, the return value (folder object with id), and provides a usage hint. It lacks details on error handling or response structure, but the absence of a output schema is partially mitigated by mentioning the return of the id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (name and space_id), achieving 100% coverage. The description adds value by explaining the role of folders (group lists, start empty) and how to use the returned folder_id with clickup_list_create, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (folder), and the context (inside a ClickUp space). It also specifies that folders start empty and that lists can be added later via another tool. This distinguishes it from sibling tools like clickup_folder_list or clickup_folder_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to use the tool after creation (adding lists via clickup_list_create) and implies the folder's role as a container. However, it does not explicitly state when to use this tool over alternatives or mention prerequisites like the need for a valid space_id, though the schema provides that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explicitly states the tool is 'destructive and irreversible,' explains that historical progress is lost, and that the goal's completion percentage is recalculated. This is beyond a simple 'delete' and adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds unique information: what it does, the consequences, and the return value. No extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the purpose, behavioral consequences, and return format. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter (kr_id) with a description that already explains how to obtain the value. Schema coverage is 100%, so the description adds only marginal value by relating the parameter's consequences on the goal. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a single key result from a ClickUp goal' with a specific verb (delete) and resource (key result). It distinguishes from sibling tools like clickup_goal_delete (deletes entire goal) and clickup_goal_update_kr (updates key result).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implicitly indicates when to use the tool (when needing to delete a key result), it does not explicitly compare with alternatives or provide usage guidance such as when not to use it or prerequisites. No siblings are named for direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states the tag is removed from every task using it but tasks are unaffected, and that the operation is destructive and irreversible. This adds essential behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the primary action, second adds critical behavioral notes. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required parameters, no output schema, and straightforward behavior, the description is fully complete. It covers purpose, effect, and safety warnings without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear descriptions for both parameters (space_id and tag_name), including provenance from other tools. The description adds no further parameter-level detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete a tag), the resource (from a ClickUp space), and the effect (removed from tasks, tasks not affected), distinguishing it from sibling tools like clickup_tag_list, clickup_tag_create, and clickup_tag_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions destructiveness and irreversibility, implying cautious use, but lacks explicit guidance on when to use this tool versus alternatives (e.g., clickup_tag_update, clickup_tag_delete). No 'when not to use' or sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses first page and compact form, but does not mention pagination mechanisms, ordering, or error handling. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, immediate guidance on alternatives, and output format. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description partially compensates by listing return fields. However, missing pagination details and any discussion of limits or error conditions reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description confirms optionality and output fields, but adds little beyond schema descriptions. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists tasks in a specific list with optional filters, distinguishing it from siblings like clickup_task_search (cross-list) and clickup_task_get (single task).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (specific list, filtering) and alternatives for cross-list or single task queries. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers key behaviors: no-op for entries without the tag, tag definitions remain unchanged, returns empty object on success. This adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. Every sentence adds information without redundancy. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detach operation with 3 parameters, the description covers all behavioral nuances (no-op, idempotency, return value). No output schema needed, as return is trivial. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for each parameter. The tool description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool detaches specific tags from time tracking entries in a single call, with explicit verb 'detach', resource, and cardinality. Distinguishes from sibling tools like clickup_time_add_tags and clickup_tag_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use compared to alternatives. Implies usage via action description but lacks guidance on choosing between this and related tools like clickup_time_add_tags or clickup_tag_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the mutation action, Enterprise plan requirement, and return of the updated object. However, it does not mention side effects (e.g., impact on child objects, member visibility changes) or reversibility, which are relevant for an ACL change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and efficiently covers object types, endpoint, plan requirement, and return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the return of the updated object, which is helpful. It lacks error scenarios or deeper ACL details, but for a focused tool, it is mostly complete. The Enterprise plan note is a critical prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so baseline is 3. The description adds value by explaining the meaning of 'private' (true = private, false = public) and noting that 'team_id' can be omitted to use the default workspace. This enriches the parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Change the privacy (ACL) of a ClickUp hierarchy object' with specific verb+resource. It distinguishes from sibling tools like clickup_space_update by focusing exclusively on privacy toggling (private/public). The mention of 'space/folder/list' and the v3 ACL endpoint provides precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: changing privacy of hierarchy objects. It notes the Enterprise plan requirement and references list endpoints for obtaining IDs. However, it lacks explicit when-not-to-use guidance or comparison with alternative update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool extracts from the Get Task response (no dedicated endpoint) and lists the fields returned. However, it does not mention authorization requirements, rate limits, or confirm read-only behavior (though implied). This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, followed by supplementary implementation details and a sibling reference. No extraneous words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format (attachments array with specific fields) and the technical workaround. It adequately covers usage, parameters, and return shape for a simple list tool, though could mention pagination or limits if any exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description adds context: task_id source ('Obtain from clickup_task_list') and team_id optionality ('default workspace from config'). This adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource ('List files attached to a ClickUp task') and distinguishes itself from sibling tools like clickup_attachment_upload by noting the upload alternative. It also explains the implementation detail (extracts from Get Task response), adding purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs to use clickup_attachment_upload for adding files, providing clear context for when to choose an alternative. However, it does not state when not to use this tool or any exclusions, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. States creation and return of object with id. Does not disclose auth requirements or rate limits, but clearly implies a non-destructive create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. First sentence states purpose and differentiates, second provides workflow hint, third states return value. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, alternative for DMs, member addition workflow, and return value. Lacks permission details but schema handles team_id default. No output schema, so return value description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters at 100%. Description adds context about description being optional and return value but does not significantly deepen parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'create' and resource 'ClickUp Chat channel in a workspace'. Differentiates from sibling clickup_chat_dm for one-on-one messages. Mentions return value includes new id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus clickup_chat_dm for one-on-one messages. Also advises to add members later via channel-members endpoint. Could mention prerequisites like workspace ID but schema covers that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description correctly indicates it's a read operation returning user objects, but does not disclose permissions, rate limits, or any side effects. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous information. Action is front-loaded with 'List the users...' and the key distinction is provided succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with two parameters and no output schema, the description covers purpose, parameter origins, and what to expect in the return. Could be improved by mentioning if pagination is supported, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema with 100% coverage. The description adds valuable context on how to obtain the IDs from other tools (clickup_chat_channel_list, clickup_workspace_list) and notes the default workspace behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list', the resource 'users who follow a ClickUp Chat channel', and distinguishes from the sibling tool 'clickup_chat_channel_members' by noting that followers are a subset of members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that followers are a subset of members, helping distinguish from the sibling tool. However, lacks explicit when-to-use or when-not-to-use guidance beyond this comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly indicates it is a read operation (fetch metadata) and states what it returns, but lacks details on permissions, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and efficiently includes limitation, alternative, and return value in just three sentences with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing the fields returned (name, description, visibility, member count, latest activity) and clarifies it returns the channel object, making it reasonably complete for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by telling how to obtain channel_id (from clickup_chat_channel_list) and explaining when team_id can be omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches metadata for a single ClickUp chat channel, listing specific fields (name, description, visibility, member count, latest activity). It explicitly distinguishes from the sibling tool clickup_chat_message_list by noting it does not return messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear alternative (clickup_chat_message_list) for when messages are needed, but does not explicitly differentiate from other channel-related siblings like clickup_chat_channel_list or clickup_chat_channel_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is idempotent (create or fetch), that channels are grouped by participant set, and that it returns the channel object with its id. This provides good behavioral insight, though it omits details like permission requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences total. The first sentence defines the action, the second explains group behavior and return value, and the third provides a follow-up action. No filler or redundancy, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description is fairly complete. It explains the input parameters (team_id and user_ids) with guidance on obtaining them, mentions the participant limit, and specifies the return value (channel object with id). It lacks details about error handling or default behavior when the workspace is omitted, but overall it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds a useful constraint for user_ids: 'ClickUp permits up to 15 participants for a group DM'. This enriches the semantics marginally, but since the schema already explains parameter sources, the contribution is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create or fetch the direct-message channel between the authenticated user and one or more other workspace members'. It specifies that it handles DMs (direct messages) and group DMs, distinguishing it from other channel tools like clickup_chat_channel_create which likely deals with non-DM channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it creates or fetches a DM channel. It also advises following up with clickup_chat_message_send using the returned channel id. However, it does not explicitly state when not to use this tool or mention alternatives like clickup_chat_channel_create for non-DM channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the reply appears in the thread panel and returns the created object, but does not disclose potential side effects, permissions, or idempotency. Adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with three well-documented parameters and no output schema, the description covers the essential purpose, return value, and alternative. Minor gaps like error scenarios or threading limitations are acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no extra semantic value beyond what the schema already provides, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Post a threaded reply beneath an existing ClickUp Chat message,' specifying a verb and resource. It differentiates from the sibling tool clickup_chat_message_send by noting its use for new top-level messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs when to use this tool (for threaded replies) and when to use clickup_chat_message_send (for top-level messages), providing clear context with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses ordering (oldest first) and return structure (array with fields). Lacks mention of pagination, authentication, or rate limits, but adequate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and ordering. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return type array with field names, ordering, and sibling tool. Lacks mention of pagination or limits, but for a simple list with one param, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers comment_id fully (100% coverage). Description adds context: 'Obtain from clickup_comment_list (field: id)', which helps agent source the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists threaded replies attached to a top-level ClickUp comment, oldest first. Distinguishes from sibling clickup_comment_reply which posts a new reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit alternative: 'Use clickup_comment_reply to post a new reply to the thread.' Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions that replies appear indented and returns the created object with id, but lacks details on auth requirements, rate limits, or side effects like notification behavior (though schema covers assignee notification).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each adding essential information: action, behavior, and alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 100% parameter coverage, the description sufficiently explains the tool's purpose, behavior, and return value (new id). It lacks explicit mention of prerequisites like having a valid parent comment_id, but that is inferred from the parameter description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema with 100% coverage. The description adds no extra meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a threaded reply'), the resource ('under an existing ClickUp comment'), and distinguishes itself from the sibling tool clickup_comment_create by specifying that it is for replies, not top-level comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for threaded replies) and provides a direct alternative for a common scenario ('For a top-level comment, use clickup_comment_create instead'), guiding the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: full body replacement (no partial edits), resolution effect (strikes through, closes thread), and text rendering nuances (@mentions rendered, markdown not). However, it omits side effects like notifications for assignee changes, rate limits, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. The first sentence states the purpose, the second adds a critical behavioral note (full replacement), and the third explains a key parameter effect and return value. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function and important behaviors for a 4-parameter mutation tool without output schema. It mentions return of updated object but lacks detail on the structure. Given the lack of annotations and output schema, slightly more context on permissions or error states would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining that text is a full replacement and that resolved=true closes the thread. Parameter descriptions are detailed (e.g., assignee notification, text rendering), making semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edit' and the resources 'text, assignee, or resolution state of a ClickUp comment on a task, list, or view'. It distinguishes from creation and deletion siblings by focusing on modification and includes critical details like full text replacement and resolution behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for editing an existing comment but does not explicitly state when to use this tool versus alternatives like clickup_comment_delete or clickup_comment_create. No when-not-to-use guidance is provided, leaving the agent to infer from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns the created page object including its id, and mentions optional parameters like team_id defaulting to config. However, it does not discuss error scenarios, required permissions, or rate limits, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. First sentence states primary purpose, second adds markdown/subtitle/parent_page_id details, third describes return value and links to sibling tools. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description adequately explains the return value and relationships to other tools. It lacks details on prerequisites or error handling, but for a create tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value beyond schema: explains parent_page_id creates a page tree, content omission creates empty page for later editing, name appears in navigator, team_id defaults to config. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create a new page), the resource (inside an existing ClickUp doc), and distinguishes from similar tools by mentioning nesting via parent_page_id and referencing sibling tools like clickup_doc_edit_page and clickup_doc_get_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to add a page to a doc) and hints at alternatives (nesting with parent_page_id). However, it doesn't explicitly exclude creating a doc itself, which is covered by clickup_doc_create, but the purpose is clear enough to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the doc starts with no pages, which informs behavior. It also mentions the return value includes the doc id. It does not cover auth needs or rate limits, but overall it adequately describes the non-destructive creation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and each sentence adds value: creation, follow-up action, and optional attachment plus return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the return value (created doc object with id). It covers the core purpose, initial state, and optional parent placement. It does not mention error conditions or permissions, but for a straightforward create tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds some context about the parent being optional and that team_id can be omitted to use default, but these nuances are already implied by the schema's optionality. It does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a ClickUp doc, specifies it starts with no pages and references the sibling tool for adding pages. It also mentions optional parent attachment, distinguishing it from other doc-related tools like clickup_doc_add_page or clickup_doc_edit_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating a new doc) and what to do next (add pages via clickup_doc_add_page). It also notes the optional parent attachment. However, it does not explicitly state when not to use it or list alternatives beyond the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses that task_count is a string 'per API', which is a notable behavioral detail not in the schema. It also clarifies that it returns the folder object with child lists. However, it does not explicitly state that the operation is read-only or mention any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key purpose and return details, and includes a concise alternative usage. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description adequately explains what the tool returns and provides an alternative for a related task. It could be slightly improved by noting that it returns a single folder object with nested lists, but overall it is clear and sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for folder_id. The tool description does not add further meaning to the parameter beyond what the schema already provides (ID of the folder to fetch). The mention of 'Obtain from clickup_folder_list' is already in the schema. Hence, no extra value is added for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'full object for a single ClickUp folder' and enumerates specific fields (name, task_count, archived status, child lists). It distinguishes itself from siblings like clickup_folder_list (which lists folders) and clickup_list_list (which lists lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly provides an alternative tool usage: 'Use clickup_list_list with folder_id to get just the lists.' This instructs the agent when to choose a different tool. However, it does not explicitly state when not to use this tool or broader context like whether it works for archived folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that only rename is possible and returns the updated folder object, but does not mention authorization needs, rate limits, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and followed by important limitation and output information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool, the description adequately covers purpose, limitation, and return value. Lacks error scenarios but is sufficient given the tool's simplicity and no output schema requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description does not add parameter-level details beyond what the schema already provides. It repeats the overall action but no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'rename' and the resource 'ClickUp folder', and distinguishes this from moving a folder by specifying that only the display name can be changed. Differentiates from sibling tools like clickup_folder_create and clickup_folder_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (rename) and when not to (to move to a different space, delete and recreate). Provides an alternative approach via sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses key behaviors: the goal starts empty, percent-complete is auto-calculated from key results, and it returns the created object with its id. It does not discuss permissions or default field values, but covers core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise, front-loaded sentences. Each sentence serves a distinct purpose: stating the action, explaining follow-up and auto-calculation, and describing the return value. No unnecessary words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains the return value and auto-calculation behavior. It also references the relevant sibling tool for the next step. This is comprehensive enough for an agent to understand usage without missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with clear descriptions. The tool description adds limited additional parameter context beyond noting that team_id can be omitted; it does not enhance understanding of the parameters beyond what the schema already provides. Following the rubric, baseline score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new OKR-style goal in a workspace, specifies it starts with zero key results, and references the sibling tool clickup_goal_add_kr for adding them, effectively distinguishing the tool's purpose from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool (to create a goal) and directs to clickup_goal_add_kr for adding key results, providing clear usage context. It does not explicitly list scenarios for avoidance, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully inform. It states it returns an array of group objects with id, name, members, which implies a read operation. However, it does not mention pagination, error conditions, permissions, or other behavioral traits beyond the basic return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that cover purpose, terminology clarification, and return format. No unnecessary words. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description provides the return shape (array of objects with id, name, members). This is sufficient for basic use, though it lacks details like pagination or field types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage. The description adds value by explaining the group_ids parameter's optionality and the team_id parameter's default behavior, including how to obtain the ID from another tool. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists user groups (teams) in a workspace, explains what a group is, and mentions the return format. It distinguishes itself from sibling tools like clickup_group_create by focusing on listing. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need to list groups. It does not explicitly mention when not to use or provide alternatives, but since it is the only list-groups tool among siblings, the context is clear. Slight lack of exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses atomicity and return value ('Returns the updated group object'). However, with no annotations, it doesn't cover permissions, side effects, or error conditions, leaving some behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with good parameter descriptions, the description covers purpose, usage, and return value. Lacks examples or error info, but sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value: explains that add_members is additive, rem_members is no-op if not a member, and name can be omitted to keep current name. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rename a user group and/or add/remove its members.' This specifies the verb (rename, add/remove) and the resource (user group), distinguishing it from siblings like create, delete, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Use clickup_group_list first to see current membership' and 'All changes are applied in one call.' This helps the agent understand preconditions and atomicity, but lacks explicit when-not-to-use or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that subtasks and parent list are not shared, and that it returns the updated guest object. It also reveals the Enterprise plan requirement. Missing details like whether it modifies existing permissions or error states, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. First sentence defines action and scope, second gives revocation alternative, third states requirement and return. Every sentence is essential and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations or output schema, yet the description covers purpose, scope, counterpart tool, plan requirement, and return type. It lacks discussion of error conditions or permission prerequisites, but is sufficient for a focused sharing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value by hinting at source tools for guest_id and task_id, but does not provide new semantic meaning beyond the schema. The permission values are clearly listed in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (grant access), resource (guest to a single task), and scope (not subtasks/list). It also distinguishes from sibling tools like clickup_guest_share_folder by emphasizing the strict task-level sharing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context and mentions the opposite tool (clickup_guest_unshare_task) for revocation. Also notes the Enterprise plan requirement. Could be improved by explicitly advising when not to use (e.g., for broader access, use folder/list sharing tools), but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the mutual exclusivity constraint and return behavior (id provided). However, no annotations exist, so the description should also cover error cases or required permissions, which are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, parent selection, and return value usage. While it doesn't detail error handling or all param effects (e.g., due_date), the schema fills those gaps. Good for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the mutual exclusivity and return id usage, enhancing semantic understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 task list and specifies the parent context (folder or space). It distinguishes from sibling tools like clickup_task_create by focusing on list creation and returning a new id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that exactly one of folder_id or space_id must be provided, guiding correct invocation. It also hints at using the returned id for related calls like clickup_task_create, but could add more on when not to use (e.g., alternatives).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the return ('Returns the updated list object') but does not mention potential permissions, error conditions, or side effects beyond modification. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a return statement, front-loaded with purpose. Every sentence adds value: purpose, alternatives, return. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description states the return value. The tool has 5 parameters with full schema coverage, and the description provides enough context for this simple update operation. Mentions alternatives for related actions, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter information beyond what the schema already provides, but the schema itself has thorough descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify a ClickUp list's name, description, due date, or status', specifying a specific verb and resource. It also distinguishes from sibling tools by mentioning alternatives for moving tasks and multi-list membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit alternatives are given: 'To move tasks between lists use clickup_task_move, and to add or remove this list from tasks with multi-list membership use clickup_list_add_task / clickup_list_remove_task.' This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output format (array of user objects with fields) and the parameter constraint. However, it does not describe permissions required, rate limits, or any side effects, leaving some behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and constraint, second covers return format and related tools. No redundant information. Front-loaded with essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return type and fields. Cross-references to sibling tools for related actions. Lacks mention of pagination or error scenarios, but overall sufficient for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description adds value by reinforcing the mutual exclusivity of list_id and task_id and specifying that exactly one must be provided, which is not enforced in the schema (required empty).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists members (users with direct access) of a task or list, using specific verbs and resources. It differentiates from sibling tools by mentioning addition of workspace members (clickup_user_invite) and guest sharing (clickup_guest_share_task/list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (list members) and directs to alternative tools for adding users. Mentions the 'exactly one' constraint. Lacks explicit 'do not use when' conditions but provides sufficient guidance for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses partial update behavior and incremental assignee changes, and mentions return value. However, it does not address permissions, error handling, or potential side effects like irreversible changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that front-load the purpose and fields, then add partial update behavior, then direct to siblings and mention return. No unnecessary words, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description states it returns the updated task object, which is sufficient. Covers updatable fields, partial update, and sibling guidance. Could add error conditions or prerequisites, but overall complete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a clear description. The tool description adds summary-level context but no new semantic detail beyond what schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing ClickUp task and lists the specific fields (name, description, status, priority, assignees). It distinguishes itself from sibling tools like clickup_task_add_tag and clickup_task_move by directing to them for related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs. alternatives: for tags use separate tools, for moving lists use clickup_task_move. Also explains that only provided fields change, omitted fields keep current value, guiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool creates an entry and returns the created object, but does not mention permissions, side effects, or other behavioral traits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: core function, usage guideline, return value. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what it does, when to use, return value. Missing discussion on optional parameters (task_id, team_id), but schema covers those. Adequate for a simple create tool with high schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters in detail. The description does not add new semantic meaning beyond what's in the schema, thus baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a historical time tracking entry with a fixed start and duration. It distinguishes from sibling tools by explicitly mentioning clickup_time_start/stop for live timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (backfilling time) and when not to (for live timing, use clickup_time_start/stop). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: if a timer is already running, it will be stopped first. Also notes return value. Lacks mention of permissions or rate limits, but with no annotations, the description adequately covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding unique value (purpose, auto-stop, pairing, return). Front-loaded with primary action. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains the action, side effect, companion tools, and return type. Sufficient for an agent to use correctly, though error handling is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in schema. Description adds no extra meaning beyond what schema provides, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Start a live time-tracking timer for the authenticated user,' specifies the resource (timer), and distinguishes from siblings by naming clickup_time_stop and clickup_time_current.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit pairing with clickup_time_stop and clickup_time_current, giving clear usage context. Does not explicitly state when not to use, but the guidance is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'Returns the user object' but does not disclose error behavior, permissions, or whether the operation is read-only. The description is adequate but lacks depth given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then provide usage guidance. Every sentence adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple fetch operation. The description lists returned fields (username, email, color, profile picture, role) and identifies siblings. With no output schema, the description provides a reasonable overview, though it could be slightly more detailed on error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both team_id and user_id have clear descriptions in the input schema. The description adds minimal additional meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and specific resource: 'Fetch the profile of a specific member of a ClickUp workspace.' It lists fields like username, email, color, profile picture, role. Explicitly distinguishes from siblings: clickup_member_list for task/list members and clickup_whoami for the authenticated user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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: 'Use clickup_member_list for task/list members; use clickup_whoami for the authenticated user.' This directly guides the AI agent on selecting the correct tool and avoiding misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It notes that inviting a paid member consumes a member seat (side effect). However, it does not clarify other behavioral details such as whether an invitation email is sent, time to effect, or error handling for duplicate emails. Schema covers email uniqueness constraint but description omits it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main action, uses of alternatives, and return value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, key side effect, and alternative tool. No output schema, but mentions return object. Could include more detail on the returned user object fields or invitation behavior, but enough for a simple invite operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds context for team_id (default workspace) but otherwise mirrors schema. No significant new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (invite a new paid member), resource (workspace), and method (by email). It distinguishes from sibling clickup_guest_invite, indicating scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (invite paid members), when not (use clickup_guest_invite for external collaborators), and mentions checking seat availability via clickup_workspace_seats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only with 'Fetch'. Mentions pagination and that results respect view configuration. Does not detail return structure beyond 'paginated array of task objects', but sufficient for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, it still describes return as paginated task array. Adequately covers how to use the tool and related tools, but could mention that tasks are immutable (not modified).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description adds value by clarifying page indexing, default, limit, and how to obtain view_id from clickup_view_list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches tasks from a ClickUp view, with specific mention of respecting filters, sort, and grouping. Differentiates from sibling tools by referencing clickup_view_list and clickup_view_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions to use clickup_view_list to discover view IDs and clickup_view_get for definition. Lacks explicit when-not-to-use but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool registers an endpoint that receives POST events, optionally scoped, and returns a secret for signature verification. However, it does not mention authorization requirements, rate limits, or behavior on failure, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then optional scoping, then a critical note about the secret. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is fairly complete: it covers the action, scoping options, and a key return field (secret). It lacks details on authentication requirements or retry behavior, but these are not critical for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 7 parameters with descriptions (coverage 100%). The description adds value beyond schema: it clarifies scoping mutual exclusivity ('Optionally scope...'), the 5-second response requirement for endpoint, and the secret for verification. This extra context benefits agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Register an HTTPS endpoint that ClickUp will POST events to'. It mentions optional scoping to space/folder/list/task, which distinguishes it from siblings like clickup_webhook_delete, clickup_webhook_list, and clickup_webhook_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to scope the webhook ('Optionally scope the webhook to a single space, folder, list, or task') and notes the 5-second response requirement in the endpoint parameter. It implies when to use (create) versus other webhook operations but does not explicitly state alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It mentions the return value (updated webhook object) and the suspend/resume capability. However, it does not cover potential side effects like whether changing the endpoint immediately stops deliveries or if the new endpoint is tested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the core action, the second provides a helpful tip. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately notes that the updated webhook object is returned. The 4 parameters are well-documented, and the tip adds practical context. Lacks detail on response field shapes, but acceptable for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all 4 parameters (100% coverage). The description adds value by highlighting the suspend/resume pattern and confirming the return object, slightly elevating it above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact resources affected (delivery endpoint, subscribed events, active status) using a clear verb ('Change'). It implicitly distinguishes from sibling tools (create, delete, list) by focusing on updating existing webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: pausing deliveries via status='suspended' and resuming with 'active'. While it doesn't explicitly state when not to use this tool, the sibling context implies create/delete for other lifecycle operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds meaningful behavioral context: it indicates no side effects (read operation), lists returned fields (plan_name, plan_id), and notes feature dependencies (guests, audit logs, ACLs require Enterprise). This goes beyond the schema but could mention auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: first clearly states the tool's action and output, second adds nuance about feature implications and return object. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately summarizes the return as a plan object with plan_name and plan_id, which is sufficient for a simple read tool. It could mention that the plan object may contain additional fields, but the current level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter team_id has 100% schema coverage, but the description adds value by specifying the source of the ID ('Obtain from clickup_workspace_list') and explaining the default behavior when omitted. This extra context helps the agent use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the current subscription plan of a ClickUp workspace, listing possible plan names (Free, Unlimited, Business, Business Plus, Enterprise) and specifying it returns plan_name and plan_id. This is distinct from other workspace tools like workspace_list or workspace_seats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get subscription plan details) but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. The parameter hint about omitting team_id to use default workspace is helpful but doesn't address trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the text replaces the entire body (not appended), returns the updated object, and that a 403 error occurs for unauthorized users. This covers key behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: first states purpose, second adds authorization constraint, third explains replacement behavior and return type. No fluff, front-loaded with key information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with well-described parameters and no output schema, the description is complete. It covers the operation, prerequisites (authorization), behavior (full replacement), and return value. No gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for each parameter. The description does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool edits an existing ClickUp Chat message (verb 'edit', resource 'existing message'). It distinguishes from sibling tools like clickup_chat_message_send (create) and clickup_chat_message_delete (delete) by specifying the action is modification. The scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit constraints: only author or admin can edit, others get 403. It implies usage context (must have message_id from list tools) but does not name alternative tools for when to use send or delete instead. Still clear on when to use and authorization requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behavioral traits: removals are scoped to own reaction, no-op on missing reaction, and returns empty object on success. This is sufficient for a simple mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and behavior with no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward reaction removal tool with no output schema, the description fully covers what the tool does, its side effects, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for all three parameters. Description does not add additional semantics beyond acknowledging exact emoji match; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Remove the authenticated user's emoji reaction') and the resource ('from a ClickUp Chat message'). Differentiates from sibling tools like clickup_chat_reaction_add and clickup_chat_reaction_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: only removes own reaction, other users' reactions preserved, and is a no-op if not reacted. While no direct alternative comparison, it clearly defines when and what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns an array of custom field definitions with specific details (field id, name, type, and option values for drop_down/labels). Implicitly read-only, but not explicitly stated. Adequate for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences packed with useful information. First sentence enumerates returned fields, second sentence gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description covers purpose, input, and output details. No output schema, but description explains return shape sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, already explaining list_id as the list ID and how to obtain it. The description adds no further parameter semantics beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists custom field definitions on a ClickUp list, specifying exact fields returned (id, name, type, etc.) and extraction of option values from type_config.options. It distinguishes itself from related siblings like clickup_field_set and clickup_field_unset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before clickup_field_set to learn field_id, option ids, and value shape. Also mentions obtaining list_id from clickup_list_list. Lacks explicit guidance on when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full burden for behavioral disclosure. It states the tool returns a goal object with key_results array, implying it's a read operation. However, it doesn't explicitly confirm no side effects, no state changes, or potential errors beyond the permission note in the parameter description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, each serving a purpose: the first explains what the tool does and what it returns, the second confirms the return structure. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects or enums), the description fully covers what an agent needs to know: what action is performed, what data is returned, and how to get the input parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter goal_id is fully described in the schema. The description adds context: how to obtain it (from clickup_goal_list) and access requirements, which is valuable beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fetch a single ClickUp goal' and lists the data it returns (key results, owners, due date, percent-complete). It distinguishes itself from sibling tools like clickup_goal_list (which lists many goals) and clickup_goal_update (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need detailed information about a specific goal. It also hints at where to get the goal_id (from clickup_goal_list). However, it doesn't explicitly state when not to use or mention alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the return format as a compact array of objects, implying a read-only operation. However, it lacks details on potential pagination, rate limits, ordering, or error conditions beyond what is implied by listing. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that efficiently convey the tool's purpose, context about goals, return format, and an alternative. No unnecessary words or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, return format, and an alternative. It could mention potential pagination or ordering, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the team_id parameter with 100% coverage. The description adds value by explaining how to obtain the team_id from another tool (clickup_workspace_list) and the optional default behavior. This provides actionable guidance beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all ClickUp goals in a workspace, describes their OKR-style nature, specifies the return array fields (id, name, percent_completed, due_date), and differentiates from the sibling tool clickup_goal_get which returns full goal details including key results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear alternative by directing users to clickup_goal_get for full goal details, and explains when to omit the team_id parameter to use the default workspace. However, it does not explicitly state scenarios where this tool should not be used or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses the destructive and irreversible nature, that historical records remain, and that individual users are unaffected. It also notes the return value (empty object). This is transparent for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words: first sentence states the action, second explains consequences and return value. It is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description covers the purpose, behavioral details, and return value completely. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the sole required parameter 'group_id', including a source hint ('Obtain from clickup_group_list'). The description does not add further meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a ClickUp user group', using a specific verb and resource. It distinguishes itself from sibling tools like clickup_group_create, clickup_group_list, and clickup_group_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the consequences (destructive, irreversible, effects on references and users), but does not explicitly state when to use this tool versus alternatives like clickup_group_update for deactivation. It implies use when permanent deletion is intended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: automatic invitation email, guest must accept, limited access, no paid seat consumption, Enterprise requirement, and return value. With no annotations, this provides necessary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences, each adding value. Front-loaded with the main action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool does, prerequisites, return value, and related tools. Adequate for a simple invite operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description does not add significant meaning beyond schema, but it explains the invitation flow that uses those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (invite guest user via email) and the resource (ClickUp workspace). Distinguishes from sibling tools like clickup_guest_share_task by noting subsequent sharing steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (invite guest), prerequisites (Enterprise plan, email not already used), and alternatives for sharing after invitation. Could be more explicit about not using if email already member/guest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. It correctly implies a read-only operation by stating 'List' and describes the return format, but could be improved by noting any authentication requirements or that it does not modify data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are efficient and front-loaded. Each sentence serves a purpose: main action, role definition, and return structure. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description fully covers what an agent needs: purpose, typical roles, and return format. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so the baseline is 3. The description adds context about roles but does not elaborate on the team_id parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List the custom roles defined in a ClickUp workspace', which clearly states the action (list) and the resource (custom roles). It specifies typical roles and mentions Enterprise custom roles, making it easy to distinguish from sibling tools like clickup_member_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that roles define baseline permissions, which hints at when to use this tool. However, it does not explicitly state when not to use it or provide direct comparisons with alternatives, which would improve guidance for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses that the view is created with default filters (empty) and that the result includes the new id. It honestly states limitations (customization via web UI). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a clear purpose: first states what the tool does, second explains the behavior and return value. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description adequately covers purpose, behavior (empty with defaults), return (object with id), and attachment scopes. It is fully sufficient for an agent to determine usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are already clear. The description adds no new per-parameter meaning beyond overall context (e.g., 'empty view with default filters'). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 saved view attached to a space, folder, list, or workspace. It specifies the verb (create) and resource (saved view), and distinguishes from sibling view tools like view_get, view_list, view_update, and view_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the view is created empty with default filters and that customization happens later via the web UI. This implicitly tells the agent not to attempt configuring filters through this tool, but it does not explicitly mention alternatives like view_update for modifications. Slightly lacking but still clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys behavioral traits: the file is read from disk, posted as multipart/form-data, stored on CDN, and returns the attachment object. It also notes size limits. This is above average for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: purpose, mechanism, sibling reference, and return value. No unnecessary words; front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects, no output schema), the description is complete. It covers operation, data flow, return format, and a link to the sibling tool. Minor gap: no error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, and the description adds value by explaining that the filename becomes the attachment title and that size limits apply. task_id's description guides to clickup_task_list for retrieval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 as an attachment to a ClickUp task. It includes technical details (multipart/form-data, CDN) and distinguishes from the sibling tool clickup_attachment_list by directing the user to use that for viewing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (to upload a file as an attachment) and mentions the alternative clickup_attachment_list for viewing. It could be improved by adding conditions like file size limits or prerequisites, but context is generally clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: only top-level messages, newest-first ordering, and v3 cursor pagination. Does not mention authentication or side effects, but these are minimal for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, each essential. Front-loaded with the main action and key differentiator. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the return type (array of message objects + next_cursor) and pagination. For a listing tool with this complexity and parameter coverage, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds extra context for all three parameters: channel_id from chat_channel_list, cursor from previous response, team_id from workspace_list. This provides meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists messages in a ClickUp Chat channel, specifies ordering (newest first), and distinguishes itself from the sibling tool clickup_chat_reply_list for threaded replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct context on when to use (list messages) and mentions the alternative for threaded replies. Also explains pagination cursor usage. Could be improved by explicitly stating when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly conveys destructive nature ('Permanently delete', 'irreversible') and states return value ('Returns the updated checklist object'). It does not cover permissions or rate limits, but for a delete tool, the core behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first states action and nature, second provides alternative and return info. No redundant words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two well-documented parameters and no output schema, the description is complete. It explains destructive nature, alternative, and return. Could mention error handling or permissions, but given low complexity, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, providing clear meaning for both parameters (checklist_id and item_id). The description adds no additional parameter context, but the schema is sufficient. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a single item from a ClickUp checklist', specifying the exact verb (delete), resource (checklist item), and scope (single item). It differentiates from sibling tool clickup_checklist_update_item by noting that alternative is for resolving without deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Destructive and irreversible' to warn when not to use, and provides an alternative: 'To resolve the item (mark done) without deleting, use clickup_checklist_update_item with resolved=true.' This gives clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: @mentions are recognized, markdown is not rendered (stored as literal), and the tool returns the created comment object with its new id. Since no annotations are provided, the description carries the full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each adding value. It is front-loaded with the main purpose and includes important behavioral notes without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers key aspects: action, mention rendering, markdown limitation, and return value including id for chaining. Minor gaps like error handling or rate limits are acceptable given tool complexity and parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds only the contextual note about the returned id, but does not provide additional meaning beyond what the schema offers per parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Post a new top-level comment on a ClickUp task.' It distinguishes itself from sibling tools like clickup_comment_reply and clickup_comment_update by specifying 'top-level' and noting the returned id can be used for those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While not explicitly stating when to use this tool versus alternatives, the description implies that for replying (clickup_comment_reply) or updating (clickup_comment_update), the returned id is needed. Context is clear, but no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the value's JSON shape must match the field type and provides examples. Returns empty object on success. Lacks mention of error conditions or authentication, but overall adequately transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no filler. Front-loads purpose, then provides essential type guidance and related tool references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple field-set tool, the description covers the main points: purpose, value constraints, prerequisite tool, and success return. Could mention that the operation overwrites existing values, but that's implied. Still nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all three parameters. The tool's description reinforces the value type requirements but adds minimal new information beyond the schema's own examples and instructions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets or overwrites a custom field value on a ClickUp task. It distinguishes itself from siblings like clickup_field_list (to inspect) and clickup_field_unset (to clear).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use clickup_field_list first to determine field type and option ids, and points to clickup_field_unset for clearing values. This gives clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It explains that the field definition remains intact and returns an empty object on success, covering key behavioral aspects. Could elaborate on permissions or edge cases, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with purpose and effect, and includes guidance on alternatives and return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, effect on field definition, return value, and provides a usage hint. It is complete for a simple clear operation, though it could mention permissions or preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters, achieving 100% coverage. The tool description does not add additional parameter-level details beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clears a custom field value on a ClickUp task, using the specific verb 'clear' and resource 'custom field value on a task'. It distinguishes itself from the sibling tool clickup_field_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use clickup_field_set to assign a new value instead', providing a clear alternative and indicating when to use this tool (clearing) versus setting a value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that guests are external collaborators (not paid seats), explains the scoping effect, requires Enterprise plan, and states the return (updated guest object). It doesn't mention whether permissions are additive or replace existing, but overall provides solid 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two well-structured sentences. The first sentence states the core action, and the second adds essential context (guest definition, revocation alternative, plan requirement, return). No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no output schema, no annotations), the description covers key aspects: what the tool does, what a guest is, plan limitation, and forward reference to the unshare tool. It could mention whether sharing is incremental or replaces existing permissions, but overall it's sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The description adds value by providing sourcing hints (e.g., 'Obtain from clickup_guest_get') and clarifying permission level meanings beyond the schema. This enhances the agent's understanding of how to correctly populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: granting a ClickUp guest user access to a list with a specific permission level. It uses specific verbs ('grant', 'scope') and identifies the resource ('guest user', 'list'), distinguishing it from sibling tools like clickup_guest_unshare_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use (grant guest access to a list) and references the complementary tool for revocation (clickup_guest_unshare_list). It also notes the Enterprise plan requirement. However, it does not explicitly exclude alternatives like sharing a folder instead, but the context is clear for this specific operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return value (empty object), API inconsistency between create and update color parameters. Lacks mention of required permissions but otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: purpose, usage context, and a critical gotcha. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, description mentions return behavior and suggests clickup_tag_list for verification. Lacks error handling info but covers core needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. Description adds value by highlighting the API naming inconsistency (tag_fg/tag_bg vs fg_color/bg_color).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a new tag in a ClickUp space, distinguishes from applying tags (clickup_task_add_tag) and updating tags (clickup_tag_update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that tags are space-scoped and must be created before use, mentions clickup_task_add_tag as subsequent step. Does not explicitly list when not to use but gives good usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: replaces full set, removes estimates for users not in array, body shape, and Business plan requirement. No annotations provided, so description carries full burden; it covers major behavioral aspects but omits error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage guidance with alternative, and body shape/requirements. No redundancy, front-loaded with key intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, description covers purpose, alternative, and constraints. Lacks details on return value or success/error responses, but typical for a replacement tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by explaining array behavior, highlighting 'at least one entry required', and referencing ClickUp's spec. Adds context beyond schema but could elaborate on assignee format (already in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces the full set of per-user time estimates on a task, distinguishing it from setting a single estimate. It names the specific verb 'replace' and the resource 'task estimates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to use clickup_task_set_estimate when only setting one estimate without disturbing others. Implicitly explains not to use if you want to keep estimates for users not in the array. Lacks explicit 'when not to use' but alternatives suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: it returns a paginated array of task objects and supports many filters. It does not mention rate limits or permissions, but as a read/search tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences plus an alternative recommendation. It is front-loaded with the core purpose and efficiently covers the range of filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (23 parameters, no output schema), the description mentions pagination and key filter categories. It lacks details on pagination behavior but is otherwise sufficient for understanding the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The tool description only summarizes the parameter types without adding new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches tasks across an entire workspace using ClickUp's filtered team tasks endpoint, listing many filter types. It distinguishes itself from the sibling tool clickup_task_list by noting that the latter is for single-list tasks with fewer parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer clickup_task_list for tasks in a single list, providing a clear alternative. This helps an AI agent decide which tool to use based on the scope of the search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is non-destructive to tasks, is a no-op if no link exists, and returns an empty object on success. This provides good transparency, though it could mention any prerequisites or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, effect on tasks, no-op behavior, and return value. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (empty object on success). It covers key behaviors (no-op, non-destructive). It might benefit from noting error handling or required permissions, but overall it is complete enough for a straightforward unlinking operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema. The description adds valuable context for task_id: 'Obtain from clickup_task_list (field: id) or clickup_task_get (field: linked_tasks[]).' This goes beyond the schema and helps the agent source the correct IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a bidirectional reference link created with clickup_task_link, and specifies that tasks themselves are unaffected. This differentiates it from the sibling clickup_task_link tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions this tool is for removing a link previously created, and notes it is a no-op if no link exists, guiding when to use it. However, it does not explicitly state when not to use it or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details what the new folder inherits (list structure, statuses, default fields, presets) and that it returns the created folder object. It does not mention error conditions or side effects, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise and front-loaded with the main action. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description adequately covers the functionality. It explains the template inheritance and return value. Minor gaps include lack of error handling or prerequisites beyond template discovery, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds value by noting that space_id and template_id are obtained from other tools (clickup_space_list, clickup_template_list) and reinforces the uniqueness requirement for name, beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new folder in a space by instantiating a saved folder template.' It specifies the resource (folder) and distinguishes it from sibling template application tools (like clickup_template_apply_list for lists and clickup_template_apply_task for tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the usage context: it is for creating a folder from a template, and mentions using clickup_template_list to discover templates. It implicitly differentiates from clickup_folder_create (which creates a blank folder) by focusing on template instantiation, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavior: all historical entries bearing the old name are updated, the API requires both hex colors on every call, and the response is an empty object. It does not cover permissions or rate limits but is adequate for the scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that convey the core purpose and key constraints without extraneous text. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the side effect, required fields, and return type, which is sufficient for a simple rename operation. It could mention error conditions but is largely complete given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds value by specifying how to obtain certain field values (name from clickup_time_tags, team_id from clickup_workspace_list), which aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames a time-entry tag across the entire workspace, using a specific verb and resource. It distinguishes itself from sibling tools like clickup_time_add_tags and clickup_time_remove_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on obtaining parameters from other tools (clickup_time_tags, clickup_workspace_list) and clarifies the need to pass existing colors if unchanged. However, it does not explicitly mention when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains partial-update semantics and return value, covering key behavior without listing errors or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with no filler—states purpose, partial update behavior, sibling alternatives, and output—ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it mentions return object; could note constraints like duration positivity, but overall sufficiently complete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with clear descriptions; the description adds value by reinforcing partial update and tag-related guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies a time tracking entry and explicitly contrasts with siblings for tag changes, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use this tool and directs to alternatives for tags, but lacks prerequisites or broader context like when to supply team_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes destructive nature, immediate loss of access, preservation of historical records, and return value (empty object). With no annotations, the description fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, consequences, and alternative. No unnecessary words, front-loaded with verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, parameters, consequences, and return value. Could benefit from mentioning required permissions, but given tool simplicity, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions in the schema itself. The description does not add new parameter information beyond what is in the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Remove a member from a ClickUp workspace, freeing their paid seat.' It distinguishes from siblings by mentioning clickup_user_invite for re-adding, providing specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use an alternative (clickup_user_invite for re-adding). However, does not explicitly state when not to use (e.g., cannot remove the workspace owner), though this is covered in the parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format (array of webhook objects with specified fields) and the action (list). For a read-only list operation, this is sufficient, though it could mention potential pagination or rate limits if applicable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and scope, second provides sibling tool references and return structure. No fluff, every sentence is essential and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description compensates by listing return fields. It is complete enough for an agent to understand and invoke correctly, though a note on output format or pagination would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (team_id). The description adds value by explaining the parameter can be omitted to use the default workspace from config, going beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (webhooks registered on a ClickUp workspace). It specifies what each webhook object contains (id, endpoint, events, etc.), effectively distinguishing it from sibling webhook management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions sibling tools (clickup_webhook_create/update/delete) for management, guiding when to use this tool vs alternatives. However, it omits explicit 'when not to use' scenarios, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns 'an array of user objects,' which is helpful. It does not mention any permissions or rate limits, but for a simple read operation, this is adequate. The description does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a returns line. It front-loads the core action ('List the users...') and provides immediate utility insight. Every sentence is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 simple parameters, no output schema, and no annotations, the description is complete. It explains what it does, when to use it, and what it returns. There are no gaps or ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented in the schema. The description does not add extra meaning beyond the schema, but the schema itself provides clear instructions (e.g., 'Obtain from clickup_chat_message_list'). The description's mention of 'Returns an array of user objects' adds some context but is not strictly necessary given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists users @-mentioned in a ClickUp Chat message, with a specific verb ('List') and resource ('tagged users'). It distinguishes itself from sibling tools like clickup_chat_message_list (list messages) and clickup_member_list (list members) by its specific focus on tagged users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is 'Useful for reading who a message was addressed to,' providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the sibling context makes alternatives implicit. A more explicit exclusion would elevate this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States destructive and irreversible action including threaded replies, and return type. No annotations present so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers deletion scope, irreversibility, alternative, and return format. Complete for a simple delete tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with detailed param description; description adds no further semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a ClickUp comment' with specific verb and resource. Distinguishes from sibling clickup_comment_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use alternative (clickup_comment_update with resolved=true) and notes destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses ordering (chronological), scope (top-level only), and return format (compact array with specific fields). This is sufficient for a read-only list operation, though pagination or error behavior is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, ordering, sibling tool alternative, and return format. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is complete. It specifies the return fields, ordering, and boundary (top-level only), covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for task_id. The tool description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists comments on a ClickUp task in chronological order. It distinguishes from sibling tools by specifying it returns only top-level comments and directs to clickup_comment_replies for threaded replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: use for top-level comments, and for threaded reply chains use clickup_comment_replies. It also notes chronological ordering, giving clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format (compact array of doc objects with specific fields) and pagination (v3 cursor pagination). No annotations provided, so description carries the burden; it adequately discloses read-only nature and pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, distinction from tasks, return format, alternatives, and pagination. Each sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return fields. For a simple list tool, it covers all necessary aspects: purpose, parameters, pagination, and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter (team_id) with 100% schema description coverage. Description adds context: 'Omit to use the default workspace from config.' This goes beyond the schema's base description, adding practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all ClickUp docs in a workspace, distinguishes docs from tasks, and mentions nested pages. It also differentiates from sibling tools clickup_doc_get and clickup_doc_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: lists docs in a workspace. Mentions alternatives for single doc (clickup_doc_get) and doc pages (clickup_doc_pages). Does not explicitly state when not to use, but covers main scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that KRs drive the goal's percent-complete via averaging, and explains how progress is derived for automatic vs manual KRs. It mentions return of created object. While it could mention the need for goal_id validity, the transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and purpose. It efficiently covers the KR concept, behavior for different types, and links to related tools. No wasted words, ideal length for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions 'Returns the created key result object', which is sufficient. It covers all relevant aspects: how KRs work, type-specific behavior, and a brief on how to update manual KRs. The tool has moderate complexity, and the description handles it completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description adds value by explaining the relationship between 'type' and other parameters (e.g., list_ids/task_ids only for automatic, steps_end for percentage/boolean). This contextual guidance enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a key result to a ClickUp goal, explains what a KR is ('sub-target'), and how it affects goal progress. It differentiates from the sibling tool clickup_goal_update_kr by mentioning it for reporting progress on certain KR types, making purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use 'automatic' KRs (linked tasks/lists) vs other types, and directs agents to clickup_goal_update_kr for reporting progress on number/currency/percentage KRs. It lacks an explicit 'when not to use' statement but covers key usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that a created group object with new id is returned, and that at least one initial member is required. It does not mention permissions, rate limits, or side effects, but for a creation tool the described behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences that front-load the key information. Every sentence adds value without redundancy. It is efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description provides reasonable completeness by mentioning the return of the created object. It covers creation, naming, member requirement, and workspace context. Minor gaps like name length constraints are acceptable for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds significant value beyond the schema by specifying how to obtain IDs for member_ids and team_id, giving an example for name, and explaining the default behavior for team_id. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), resource (user group/team), and context (workspace). It specifies that groups are used for @-mentions and assignments, and distinguishes this creation tool from sibling tools like group_list, group_update, etc. The UI equivalent is mentioned for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose of groups and gives a prerequisite (at least one initial member required). It provides guidance on obtaining IDs from other tools, implying a workflow. However, it does not explicitly contrast with alternatives like updating or deleting groups, though the context is clear enough from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses plan requirement and that it returns a guest object. No annotations provided, so description carries full burden. Could mention authentication scope or potential errors, but adequate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action with result, guest definition, plan requirement. No redundant words; all content is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return type, plan constraint, and parameter sources. Schema coverage is 100%, so description complements well. Could mention error handling but not essential for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds valuable guidance beyond schema: explains how to obtain guest_id (from guest_invite) and team_id (from workspace_list), including default behavior for team_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches a guest profile with specific fields (email, permissions, shared items). Distinguishes from sibling tools like guest_invite or guest_remove by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about guests being external collaborators and requires Enterprise plan. Offers parameter sourcing guidance (from guest_invite, workspace_list). Does not explicitly mention when not to use or compare to siblings like guest_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains the tool updates flags, notes plan requirement, mentions return value (updated guest object), and implies non-destructive behavior (omitting param keeps current value). Could add detail on immediacy or reversibility, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. Front-loaded with purpose, then clear exclusion, then plan and return. Every sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple update tool with no output schema. Describes functionality, constraints, return value, and boundary with sibling tools. Given the parameter count and absence of nested objects, nothing more is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter fully described. The description adds context by grouping the flags as 'workspace-wide capability flags' and explaining the return, but does not enhance individual parameter 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'a ClickUp guest's workspace-wide capability flags' with specific examples (edit tags, see time spent, create views). It also differentiates from sibling tools that handle sharing vs capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use this tool (does not change sharing) and directs to alternative tools (clickup_guest_share_* / _unshare_*). Also mentions the Enterprise plan requirement, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies read-only operation via 'Fetch' and lists returned fields. Lacks explicit statements about permissions or side effects, but sufficient for a GET-like tool given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first specifies action and output, second provides cross-tool guidance. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists all key fields returned despite no output schema. Single param with clear provenance. Sufficient for agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear param description. Tool description adds no new semantics beyond the schema, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch the full object for a single ClickUp list' and enumerates returned fields. Distinguishes from sibling clickup_task_list by specifying it returns list metadata, not tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using clickup_task_list with list_id for enumerating tasks inside a list, clarifying when to use this tool vs. the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool returns a space object with detailed attributes, implying a read-only operation. However, it could explicitly state idempotency or permissions. The description adds value beyond the name by listing what the object contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first lists returned attributes, the second provides usage guidance. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is complete. It explains what is returned and points to next steps for exploring contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is space_id, which already has a clear description in the schema. The tool description doesn't add new semantic information about the parameter, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the full object for a single ClickUp space, listing specific attributes (name, privacy, statuses, features, members). It distinguishes itself from sibling tools like clickup_space_list (lists spaces) and clickup_folder_list/clickup_list_list (enumerate contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to get full details of a single space) and directs to alternatives (clickup_folder_list, clickup_list_list) for enumerating contents, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states this is a list operation returning an array of tag objects with fields. No hidden behaviors or side effects are indicated, consistent with a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states action, second adds detail on tag properties and return format. It is concise, front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter, no output schema), the description fully covers required information: what it does, scope, return format. It is sufficiently complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers space_id with a description. The description adds extra context beyond the schema by noting that tags are defined per-space, not workspace-wide, providing meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists tags in a space using the verb 'list' and resource 'tags'. It specifies the scope is per-space, distinguishing it from sibling tag creation/modification tools and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While explicit when/when-not guidance is absent, the description implies usage by stating its purpose. It clearly differentiates from sibling tag tools (create/delete/update) by focusing on listing, and provides context that tags are space-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that task starts in default status unless 'status' supplied, and returns created object. With no annotations, it adequately covers key behavior, though does not address permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose first, then behavioral note and return value. No fluff, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple purpose and richness of schema, the description is complete. It names sibling tools for obtaining IDs and mentions return value, which is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for all 8 parameters. Description adds context on default status behavior and return value, supplementing schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Create a new task in a ClickUp list' with verb+resource. Distinguishes from siblings by mentioning return of created task with new id, which can be passed to update/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for creation; implies usage when needing a new task. Mentions subsequent use of returned id with other tools, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that tasks are not affected and returns an empty object on success. No annotations to contradict. Lacks description of error cases or idempotency, but reasonable for no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences covering action, usage direction, behavioral note, and return value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with no output schema, description covers all essential aspects: parameters, usage rule, task safety, and return value. Agent can effectively invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining mutual exclusivity of depends_on and dependency_of, and how they relate to the add operation. Provides context for task_id derivation from other tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it removes a dependency relationship between two tasks, with a specific verb and resource. References sibling tool clickup_task_add_dep for direction context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to provide exactly one of depends_on or dependency_of, matching the direction from the add operation. Implicitly advises against using both. Could mention when not to use, but adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses additive nature and return of updated object. No annotations exist, so description carries full burden. Lacks detail on permissions, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, return type, parameter sources, and alternative tool. No output schema, but description compensates. Complete for a setter with good schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. Tool description does not add new parameter info beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Set a per-user time estimate on a ClickUp task.' Distinguishes from sibling by noting additive behavior and naming clickup_task_replace_estimates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (set individual estimate) and when-not (use replace for bulk). Provides context on workload views/reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully informs the agent about destructiveness ('Permanently delete', 'Destructive and irreversible'), behavior on default views (returns 400), effect on tasks (not affected), and success return (empty object). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey all essential information without redundancy. The first sentence front-loads the purpose, followed by key behavioral notes. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description covers all necessary context: destructive irreversible action, default view restriction, no effect on tasks, and empty return on success. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (view_id) with 100% schema coverage; the schema description already explains how to obtain it and its constraints. The description adds the view types but adds limited value beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and the resource ('ClickUp view'), listing specific view types (board, list, calendar, gantt). It naturally distinguishes from siblings like clickup_view_update or clickup_view_create, as it is a deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that default views cannot be deleted and will return a 400 error, guiding the agent on when to use (only custom views) and when not. It does not name alternative tools but the context of irreversible deletion versus updating (clickup_view_update) is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states this is a fetch operation, what it returns, and what it does not return (tasks). It does not mention authorization or rate limits, but for a simple retrieval tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and include all essential details without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is fully complete: it explains what the tool returns, what it excludes, and how to get the required input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, thoroughly describing the sole parameter view_id. The description only restates the schema's instruction to obtain the ID from clickup_view_list, adding no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the full definition of a single ClickUp view, listing key components (name, type, parent scope, filters, etc.) and explicitly distinguishes from the sibling tool clickup_view_tasks by noting it does not return tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when NOT to use this tool (for tasks, use clickup_view_tasks) and explains how to obtain the required view_id from clickup_view_list, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return value as a compact array of view objects with id, name, type. No annotations provided, so the description carries the burden. It does not mention any side effects or limitations, but as a read-only list operation, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and immediately followed by key constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clearly states the return shape. It covers essential scope options and parameter relationships. Could optionally mention if there's pagination or sorting, but not necessary for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the schema by explaining the mutual exclusivity rule and how to obtain IDs from other tools (e.g., clickup_folder_list). Schema coverage is 100%, but description still adds valuable usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists saved views of various types, attached to specific scopes (space, folder, list, workspace). Differentiates from siblings by specifying the scoping rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that exactly one of space_id, folder_id, list_id must be provided, or omit all for workspace-level views. Provides context on when to use each scope, but does not explicitly mention when not to use this tool vs alternatives like clickup_view_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'Destructive and irreversible: the webhook record is removed immediately' and 'Returns an empty object on success.' However, it does not reiterate authorization requirements (found in parameter description). Still, it covers key behaviors well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each valuable: purpose, behavior, alternative use. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is complete. It covers purpose, usage guidance, behavior, and return type. There are no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already explains how to obtain the webhook_id and ownership requirements. The main description does not add additional semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Permanently delete a ClickUp webhook, stopping all future event deliveries to its endpoint.' It uses a specific verb and resource, and distinguishes from the sibling tool clickup_webhook_update for pausing deliveries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative: 'If you only want to pause deliveries, use clickup_webhook_update with status='inactive' instead.' It also warns that the action is destructive and irreversible, guiding when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the item starts unresolved and returns the updated checklist. With no annotations, the description covers key behavioral traits but could mention prerequisites like checklist existence or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence states purpose, second gives alternatives, third states return value. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return value. Distinguishes from 3 sibling checklist tools. Covers parameter sources and initial state. Could add a note on required permissions or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by specifying how to obtain assignee and checklist_id (e.g., 'Obtain from clickup_member_list'), augmenting the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (append a new item), the resource (existing ClickUp checklist on a task), and the initial state (starts unresolved). It also distinguishes from sibling tools by naming update and delete alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use this tool (to add an item) and when to use alternatives (update for editing/resolving, delete for removal). The initial unresolved state implies post-add actions if needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool returns only metadata and not page bodies, and says it returns the doc object. It could mention more about response shape, but for a simple fetch, this is adequate. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences conveying essential information with no redundancy. The first sentence states purpose, the second clarifies limitation and alternatives. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, limitations, and alternatives. It lists returned fields and mentions the doc object. Without an output schema, it provides enough context for a simple metadata fetch, though a few more details on response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by indicating that doc_id should be obtained from clickup_doc_list and that team_id can be omitted for the default workspace. This aids correct usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches metadata for a single ClickUp doc, listing specific fields (name, parent, dates, type). It explicitly distinguishes from sibling tools that return page bodies, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states what the tool does NOT do (not return page bodies) and provides two alternative tools (clickup_doc_pages, clickup_doc_get_page) for that purpose. This gives clear guidance on when to use this tool vs. siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the task remains in its home list and other secondary lists, and that it returns an empty object. It does not mention error behavior or idempotency, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences: action+context, what it does not do+alternative, return value. Every sentence adds distinct value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema), the description covers the essential aspects: purpose, usage context, return value, and differentiation from deletion. It could mention potential errors or prerequisites, but overall it's complete enough for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explicitly noting that 'list_id must not be the task's home list', which is a constraint not in the schema description. This enhances parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a task from a secondary list', and explicitly distinguishes from task deletion by saying 'The task itself is NOT deleted', which differentiates it from sibling clickup_task_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: use this to remove from a secondary list (added via clickup_list_add_task) and not to delete the task entirely (use clickup_task_delete instead). This clarifies when to use and when not to use, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description explains archiving behavior (hidden but retains data) and return value (updated space object). Lacks auth or rate limit details, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First states purpose and operations, second adds crucial behavioral nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 4 params well-documented in schema. Description covers behavior and output completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description adds extra context about archiving vs deletion and return value, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Modify a ClickUp space' with specific operations: rename, toggle privacy, archive/unarchive. Distinguishes from create, delete, get, list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about archiving as a reversible alternative to deletion, guiding when to use this tool over delete. No explicit when-not, but purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the operation is attaching a tag, returns an empty object, and requires the tag to already exist. It does not detail error behavior or potential side effects like idempotency, but for a simple additive operation, it is mostly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, followed by prerequisites and return value. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description covers purpose, prerequisites, parameter sourcing, and return type. Missing details on error handling or idempotency, but overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described). The description adds value by clarifying that tags are identified by name not ID and provides explicit sources (clickup_tag_list, clickup_task_list), going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('attach an existing tag to a ClickUp task') and resource, distinguishing it from sibling tools like clickup_tag_create and clickup_task_remove_tag. It specifies that tags are identified by name, not ID, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use (attaching a tag) and when not to (if tag doesn't exist, use clickup_tag_create first). It mentions alternatives (clickup_tag_list for checking) and conventions (name-based identification), offering complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: destructive, irreversible, cascading deletion of all subtasks, comments, checklists, attachments, time entries. Also states return value (empty object). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action description, warning with alternative, and return value. No extraneous information. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, 100% schema coverage, no output schema, the description provides all essential information: what is deleted, return type, and user confirmation requirement. Slightly lacking in prerequisites or authorization details, but sufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed description of task_id and its cascading effect. The description reinforces this but does not add new parameter-specific 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it permanently deletes a ClickUp task including subtasks, comments, etc. It uses strong action verbs and distinguishes from the sibling clickup_task_update by explicitly offering an alternative for marking done without deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to confirm with user before calling due to destructive nature, and provides an alternative tool (clickup_task_update with closed status) for non-destructive completion. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes inheritance of description, checklists, subtasks, etc., and mentions that the new task uses the supplied name. States return value. Without annotations, this provides solid behavioral insight, though permission requirements and side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: first defines action and key behavior, second offers usage guidance and return info. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, full schema coverage, and no output schema, the description covers purpose, inheritance, parameter sources, and return type. Complete enough 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, and the description adds extra meaning: source of list_id and template_id from other tools, and name override behavior. This significantly helps parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a new task by instantiating a task template, distinguishing it from related sibling tools like clickup_task_create and clickup_template_apply_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions to use clickup_template_list for discovering templates, providing helpful context. Does not explicitly state when not to use, but the purpose is clear enough to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses endpoint, return values (ok:true or error), and error conditions (missing, malformed, expired, revoked). Without annotations, this is nearly complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with essential information and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it explains return values and errors. Provides context and alternative tool. Fully complete for an auth check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so description adds nothing beyond schema. Baseline 4 for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it verifies API token validity by hitting /user endpoint, and distinguishes from sibling clickup_whoami.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (token check) and when to use alternative (clickup_whoami for profile).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds that it returns the updated channel object. Does not mention permissions or side effects, but adequate for a simple update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by exclusion and return info. No verbose or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description mentions return value. Clearly covers the two updatable fields (name, description) and identifies required param. Complete for its functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds useful hints like obtaining channel_id from list tool and uniqueness constraint for name, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames a chat channel or changes its description, with specific verbs and resource. It distinguishes from sibling tools for membership/visibility changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs to use channel-members and channel-followers tools for membership/visibility changes, providing clear when-not and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behavior: creates a new top-level message and returns the message object with id. It does not mention potential side effects or limitations, but the core mutation is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. The first states the core purpose, the second covers alternatives, return value, and chaining. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers purpose, usage boundaries, return value, and parameter sourcing. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds value by explaining how to obtain IDs from other tools (channel_id from clickup_chat_channel_list, team_id from clickup_workspace_list) and notes the default for type. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Post a new top-level message to a ClickUp Chat channel' and distinguishes from sibling tools for replies and DMs, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (top-level messages) and when to use alternatives (clickup_chat_reply_send for replies, clickup_chat_dm for DMs). Also suggests how to use the returned id for reactions and replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden by stating 'permanently delete', 'destructive and irreversible', and 'returns an empty object on success', providing clear 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the first stating the core purpose and scope, and the second providing alternative and return value—no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers purpose, scope, alternatives, destructiveness, and return value. No output schema needed; completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter's own description is comprehensive, explaining where to get the checklist_id and consequences. The tool description adds no extra parameter semantics beyond that, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'entire checklist from a ClickUp task', and distinguishes itself from the sibling tool clickup_checklist_delete_item by specifying scope (all items vs single item).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this ('remove a single item instead, use clickup_checklist_delete_item') and flags it as destructive and irreversible, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes scope clearly (no effect on items). Without annotations, this is good but could mention permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading purpose and exclusions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, covers purpose, scope, and return. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all params fully. Description adds context about what the update does and what it doesn't affect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (rename/change position) and resource (checklist). Distinguishes from siblings by specifying what it does not affect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternative tools for item operations. Also states return value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description fully discloses the destructive, irreversible, and cascading behavior. It also indicates the return value (empty object). No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Key information (destructive, irreversible, alternative) is front-loaded, and the return type is mentioned at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, side effects, user confirmation requirement, alternative approach, and return value. Adequate given no output schema or additional complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes folder_id's purpose and source (from folder_list) and cascading effect. The description adds no new parameter-specific information beyond reinforcing the destructive nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool permanently deletes a folder and all its contents (lists and tasks). It clearly distinguishes from archival by mentioning clickup_space_update with archived=true, avoiding confusion with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises confirming with the user before calling due to destructive nature. Provides a clear alternative (archival via clickup_space_update) with explanation of reversibility, guiding correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states the return format as 'a compact array of folder objects (id, name, task_count, archived)', which is transparent for a read operation. It does not explicitly confirm read-only behavior, but the context implies it. The description could mention that no side effects occur, but the provided details are adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, context, alternative, and return format. No unnecessary words. The description is front-loaded with the primary action and uses the second sentence for differentiation. Extremely concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, full schema coverage, no output schema, and a simple list operation, the description provides sufficient context. It covers what the tool does, when to use alternatives, how to get required IDs, and what the output looks like. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters are already well-described in the schema. The description adds value by telling the user to obtain space_id from clickup_space_list, which goes beyond the schema. This extra guidance improves parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List all folders in a ClickUp space', clearly stating the action and resource. It distinguishes from clickup_list_list by noting that spaces may have folderless lists and directing users to that tool for those. This differentiates it from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Folders are optional groupings that contain lists; a space may also have folderless lists (use clickup_list_list with space_id for those).' This tells when to use this tool and when to use the alternative, providing clear context and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and clearly states the irreversible, cascading nature, loss of historical progress data, and the return value ('empty object on success').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no wasted words: purpose, warning, and return value. Every sentence adds critical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is complete—it covers action, consequences, parameter acquisition, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by telling the agent how to obtain the goal_id ('from clickup_goal_list (field: id) or clickup_goal_get').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and the resource ('ClickUp goal along with all its key results'), distinguishing it from sibling tools like clickup_goal_delete_kr and clickup_goal_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly warns the agent to 'confirm with the user before calling' due to destructiveness, but does not explicitly mention when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses: permanent action, deletion of share-records, inability to log in, irreversibility, plan restriction, and return type (empty object). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with key action, no redundant information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all critical aspects: action, consequences, prerequisites (plan), return value, and references to sibling tools. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides detailed descriptions for both parameters (guest_id and team_id) with 100% coverage. The description reinforces effects but adds minimal new information beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the action as permanently revoking a guest user's access, with specific verb 'revoke' and resource 'guest user'. Differentiates from siblings like clickup_guest_update (modify) and clickup_guest_invite (add).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states destructive/irreversible nature and provides alternative tool for re-invitation (clickup_guest_invite). Also mentions Enterprise plan requirement, guiding appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the action grants access to all descendant lists and tasks, that it returns the updated guest object, and implies the Enterprise plan requirement. It does not address potential side effects like permission overrides, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first defines the action and scope, the second provides alternatives and reversal, the third states plan requirement and return value. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the return value ('updated guest object') sufficiently. All three parameters are explained with sourcing guidance. The description covers purpose, usage, and result without missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already having a description. The tool description adds value by advising how to obtain each parameter (e.g., 'Obtain from clickup_folder_list (field: id)') and by clarifying that the permission value applies to every descendant, which is slightly more explicit than the schema's phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Grant a ClickUp guest user access to an entire folder — including all its lists and tasks — at a specified permission level.' It distinguishes from siblings by mentioning narrower-scope alternatives (clickup_guest_share_list, clickup_guest_share_task) and the revocation counterpart (clickup_guest_unshare_folder).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for folder-level access) and when to use alternatives (list or task sharing). It also mentions the Enterprise plan requirement and notes that the result is an updated guest object, which helps the agent decide invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cascading behavior (revokes folder-level access to all lists/tasks under it), preservation of separate list/task grants, and the requirement for Enterprise plan. No annotations, so description fully bears the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing essential information: action, preservation detail, and alternative/requirement. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers the tool's purpose, behavior, parameter sources, return value, and requirements. No gaps given the tool's simplicity and the presence of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters (how to obtain folder_id and guest_id). The description adds no additional parameter meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Revoke a guest user's access to a folder' with cascading effect to lists and tasks. It distinguishes from siblings like clickup_guest_share_folder, clickup_guest_unshare_list, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (revoke folder-level access while preserving separate grants) and provides an alternative (re-share with clickup_guest_share_folder). Also mentions Enterprise plan requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses immediate loss of access ('destructive'), that the guest account remains, and specifies the Enterprise plan requirement. Returns updated guest object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each essential. No filler. Front-loaded with purpose, followed by side effects and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effects (guest keeps other grants), destructive nature, reusability (guest account remains), plan requirement, and return value. Complete for a simple revocation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds value by cross-referencing how to obtain parameters (e.g., 'Obtain from clickup_guest_get') and clarifying which list's access is revoked.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revoke a guest user's access to a specific list') and distinguishes from siblings by noting that other grants persist and by referencing the complementary tool clickup_guest_share_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use context: revoking list-level access for a guest. Mentions destructive nature and Enterprise requirement. Does not explicitly list when to use alternatives but contrasts with resumption via share_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the task is not moved, remains in its original list, and returns an empty object on success. However, it could further mention idempotency or error conditions. Still, it covers the key behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action and purpose, no unnecessary words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description fully covers the purpose, usage, parameter sourcing, and return value. It is complete for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by specifying how to obtain the IDs (from clickup_list_list and clickup_task_list), which is helpful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add to secondary list), the resource (task), and explicitly distinguishes it from moving by mentioning the task remains in its home list. It also references the sibling tool clickup_task_move for alternative behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus the alternative clickup_task_move ('To change the home list instead, use clickup_task_move'). This clarifies the exact use case for multi-list membership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes destructive, irreversible, cascading nature and return value. No annotations, so description carries burden; missing authentication/rate limits but otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load action and consequence, then provide usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effects, return value, and alternatives. Complete for a single-parameter destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter list_id described in schema (100% coverage); description adds context that all tasks inside are deleted with it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it permanently deletes a ClickUp list with all tasks, comments, checklists, and attachments. Distinct from siblings like clickup_list_update and clickup_task_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to confirm with user before calling and provides alternatives: move tasks with clickup_task_move or use clickup_list_update to rename/archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format ('compact array of list objects (id, name, task_count, archived)') and the mutual exclusivity constraint. Could mention any authentication requirements or rate limits, but is sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose and constraint, second sentence describes return value and provides alternative tool. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters, no output schema, and no annotations, the description covers all necessary aspects: what it does, required parameters, return structure, and relation to sibling tools. Complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by clarifying that space_id returns folderless lists and reinforcing the mutual exclusivity. The description also explains how to obtain folder_id/space_id from other tools (clickup_folder_list, clickup_space_list), which the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List ClickUp lists under either a folder or a space (folderless lists)'. Specifies verb, resource, and context. Distinguishes from sibling clickup_task_list by indicating when to drill into a specific list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that exactly one of folder_id or space_id must be provided. Provides alternative tool (clickup_task_list) for drilling into a specific list, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the irreversible, cascading destructive behavior and notes the return value (empty object). With no annotations, this covers key behavioral traits, though it omits authorization requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an instruction. Every sentence serves a purpose: stating the primary action and its scope, warning about destructiveness, and providing an alternative. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a single parameter and no output schema, the description covers purpose, usage guidelines, parameter sourcing, and behavioral notes. It could mention required permissions, but overall is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with one parameter. The description adds value by explaining how to obtain the space_id (from clickup_space_list), and reiterates the cascading deletion scope, which the schema's description also mentions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool permanently deletes a ClickUp space and all its contents. It specifies the verb 'delete' and resource 'space', and distinguishes from sibling tools like clickup_space_update (archival) and clickup_folder_delete (different level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to confirm with the user before calling due to destructiveness. Provides an alternative (use clickup_space_update with archived=true) for reversible hiding, which guides when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a compact array with specific fields (id, name, private, archived) and describes the archived parameter's effect. No mention of rate limits or authentication, but the operation is clearly a read-only list. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second adds context about hierarchy, third provides return type and drill-down guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description explains return shape. Both parameters are well-documented with usage hints. Sibling tools for drilling down are referenced. Complete for a list tool with simple configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema: for team_id, it explains the omission behavior using a config default; for archived, it clarifies true/false/omit. This provides actionable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all spaces in a ClickUp workspace' after the tool name, defining the verb (list) and resource (spaces). It also distinguishes from siblings by naming clickup_folder_list and clickup_list_list as tools to drill down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Use clickup_folder_list or clickup_list_list with a space_id to drill down.' It tells the agent when to use this tool and when to use alternatives, and explains the compact return format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: 'All tasks using the tag are automatically updated with the new name/colours' and 'Returns an empty object on success'. This provides complete transparency about side effects and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded: first sentence states purpose, second explains behavior, third adds critical API note. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (updating a tag) and the description covers purpose, behavior, return value, and an important inconsistency note. No output schema exists, but the description adequately specifies the return. All necessary context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by highlighting the API inconsistency (fg_color/bg_color vs tag_fg/tag_bg) which helps agents use the correct parameter names. However, it does not elaborate on parameter meanings beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename a tag or change its colours within a ClickUp space', specifying the verb (rename/change) and resource (tag). It distinguishes from sibling tools like clickup_tag_create, clickup_tag_delete, and clickup_tag_list by noting the API inconsistency, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (to update tag name/colors) and provides a crucial note about the API inconsistency between tag_update and tag_create. It implicitly differentiates from sibling tools (create, delete, list) but could be more explicit about when not to use this tool (e.g., for creating new tags).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the relationship semantics (blocks/wait) and the return value (empty object on success). It effectively conveys the core behavior beyond the input schema. While it doesn't detail error conditions or side effects, the function is simple and well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a clear purpose: first sentence states the tool's purpose and the two modes, second sentence gives usage guidance and mentions the return value. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description covers the return value. All parameters are thoroughly documented in both schema and description. The tool is simple and the description provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds meaning by explaining the roles of each parameter, the mutual exclusion between depends_on and dependency_of, and where to obtain task IDs (from clickup_task_list). This goes beyond just the parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a dependency relationship between two tasks, and specifies the two possible directions (task_id depends on depends_on or dependency_of depends on task_id). It also distinguishes itself from clickup_task_link for simple non-blocking references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (to create a dependency) and when to use an alternative (clickup_task_link for non-blocking references). It also instructs to provide exactly one of depends_on or dependency_of, clarifying the mutual exclusivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the bidirectional nature, visibility in 'Linked tasks' panel, and that it returns an empty object on success. With no annotations, this covers the key behavioral aspects, though could mention if it overwrites existing links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with the core purpose, then provides removal and alternative usage. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has low complexity with 2 parameters and no output schema. Description mentions successful return type, explains bidirectional nature, and includes ID source instructions. Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. The description adds value by specifying how to obtain parameter values (from clickup_task_list) and clarifying visibility for links_to. This goes beyond repeating schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a bidirectional reference link between two tasks, emphasizing it is a non-blocking 'see also' relationship. Distinguishes from dependencies, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus alternatives: use clickup_task_unlink to remove, and for blocking relationships use clickup_task_add_dep. Provides clear guidance on alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it is a non-destructive removal (preserves tag definition), no-op if tag not present, and returns an empty object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing essential information: action, side-effect, and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with well-documented parameters and a clear description of behavior and return, this is complete. The no-op clarification and empty object return are particularly helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, and the description adds useful context (case-sensitivity, cross-reference to clickup_task_get for tag names). This enhances the agent's understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Detach a tag from a ClickUp task') and distinguishes it from sibling tools by specifying it preserves the tag definition and only removes the association.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use (to remove a tag) and mentions no-op behavior, but lacks explicit guidance on when not to use or direct comparison with alternatives like clickup_task_add_tag or clickup_tag_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses authorization requirements and that it returns the updated user object. It adds value beyond annotations by clarifying the scope of changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose, authorization, and guidance on alternatives. Every sentence is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, authorization, parameter usage, and return value. Given no output schema, the mention of 'Returns the updated user object' is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and clear descriptions. The description adds context about who can invoke the tool and that it returns the updated object, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update a ClickUp workspace member's username and/or admin role', specifying the action, resource, and updatable fields. It distinguishes itself from sibling tools by mentioning alternatives like role-based endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on who can call the tool ('Only the authenticated user (if self) or a workspace admin'), and when not to use it ('To change per-item permissions use role-based or share endpoints instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it updates a view and returns the updated object. With no annotations, the description adequately covers the mutation behavior and expected output, though it could mention 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, first sentence states purpose, second provides limitations, third states return value. No redundant information, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three required parameters and no output schema, the description covers all necessary aspects: action, limitations, parameter source, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the schema (100% coverage). The description adds value by specifying the source for view_id (clickup_view_list) and listing the allowed view types, exceeding schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renames a view or changes its display type, with specific verbs and target resource. It distinguishes from sibling tools like view_create, view_delete, view_get, view_list, and view_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states what the tool can and cannot do, and directs users to the web UI for filters/grouping/sorting. This provides clear guidance on when to use and when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses the tool's behavior: it is destructive, irreversible, cascading (deletes messages and replies), removes the channel for all members, and returns an empty object. This exceeds transparency expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus parameter details, all front-loaded with key information. Every sentence serves a purpose: stating the action, emphasizing destructiveness, advising user confirmation, and specifying the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description covers the return type. It fully explains the tool's effects, prerequisites (user confirmation), and scope (workspace-wide). For a delete tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema by telling users where to obtain channel_id and team_id (from specific list tools) and reminding that channel deletion cascades to messages. This is crucial for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ClickUp Chat channel along with all its messages and replies. It uses strong verbs like 'permanently delete', 'destructive', and 'irreversible', making the purpose unambiguous and distinct from siblings like update or get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to confirm with the user before calling, providing a clear when-to-use guideline. It does not explicitly list alternatives or when not to use, but the destructive nature implies it should be used sparingly. Still, it provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the transparency burden. It explains how content modes work, that names can be changed or kept, and that IDs come from other listed tools. It lacks detail on auth or rate limits, but for an edit operation the described behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each serving a purpose: state primary action, explain modes, offer alternative tool, and indicate return value. No fluff, front-loaded with the most important information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description still mentions 'Returns the updated page object.' It covers all major behavioral aspects, parameter sourcing, and mode variations. For a 6-param tool with 2 required, this is fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have 100% schema description coverage. The description adds context beyond the schema by noting default behaviors (e.g., 'Omit to leave content unchanged', 'Omit to keep current title', 'Omit to use default workspace') and sourcing hints. This enriches the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renames or rewrites existing pages in ClickUp docs, differentiating from clickup_doc_add_page for new pages. The verb 'rename' and 'rewrite' plus resource 'existing page' make purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains default replace behavior and mode options (append/prepend), and explicitly guides users to use clickup_doc_add_page for fresh pages. This provides clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but description fully discloses destructive nature, removal of threaded replies, permission requirements, and return value ('empty object on success').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences; each sentence adds distinct information without redundancy. Critical details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple 2-param tool with no output schema, description covers all necessary context: action, scope, permissions, error condition, and success result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema: message_id references where to obtain it, team_id notes optional default behavior. Schema coverage is 100% but description enriches each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'permanently delete a message' and specifies 'from a ClickUp chat channel or DM thread', clearly distinguishing it from sibling tools like update or send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: describes irreversibility, who can delete (author or admin), and what happens on unauthorized attempt (403 error). Implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it is destructive and irreversible, returns an empty object on success, and mentions ownership/admin restrictions for deletion. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, behavioral warning, alternative usage, and return info. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description specifies empty object return. It covers permissions, provides cross-reference to sibling tool, and addresses schema parameter origin. Fully complete given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: where to obtain the team_id (from clickup_workspace_list) and timer_id (from clickup_time_list), plus ownership requirements for timer_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Permanently delete a recorded time tracking entry') and resource. It distinguishes itself from the sibling tool clickup_time_stop by noting that this tool is for deletion while the sibling is for stopping a timer that preserves the record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Permanently delete') and when not to, providing an alternative ('To stop a currently running timer, use clickup_time_stop instead'). It also warns about irreversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![clickup-cli MCP server](https://glama.ai/mcp/servers/nicholasbester/clickup-cli/badges/card.svg)](https://glama.ai/mcp/servers/nicholasbester/clickup-cli)

Score Badge

Copy to your README.md:

[![clickup-cli MCP server](https://glama.ai/mcp/servers/nicholasbester/clickup-cli/badges/score.svg)](https://glama.ai/mcp/servers/nicholasbester/clickup-cli)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nicholasbester/clickup-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server