amazing-clickup-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Tools follow a clear verb_noun pattern and descriptions explicitly state when to use and when not to use alternative tools. While there are many similar operations (e.g., multiple add_guest tools), the documentation makes them distinguishable.
Naming Consistency5/5
Nearly all tools use the clickup_verb_noun format consistently. Minor variations like 'edit' vs 'update' exist but are predictable and follow the same pattern.
Tool Count1/5
With 166 tools, the server is massively over-scoped. It covers nearly every ClickUp API endpoint, far exceeding the typical 3-15 tool range. This makes it unwieldy for agents and hard to navigate.
Completeness5/5
The tool set covers the full range of ClickUp entities and actions: tasks, lists, folders, spaces, docs, chat, time tracking, goals, custom fields, webhooks, etc. There are no obvious gaps.
Average 4.7/5 across 166 of 166 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that if a channel with the given name already exists, the tool returns the existing channel instead of creating a duplicate, which is idempotent behavior. However, the annotation idempotentHint=false directly contradicts this, causing confusion about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main description, usage, examples, errors) and is concise without extraneous information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage guidelines, alternatives, return format, error handling, and defaults (e.g., workspace_id). While very thorough, the contradiction with idempotent hint creates a completeness issue, though the description itself is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters, so the description does not need to repeat them. However, it adds value by giving concrete examples and clarifying the 'name' parameter's duplicate-handling behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Workspace-level Chat channel by name, distinguishing it from location channels and direct messages. The verb 'create' and resource 'chat channel' are specific, and sibling differentiation is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, naming alternatives like clickup_create_location_chat_channel and clickup_create_direct_message. It also explains the idempotent behavior of returning existing channels, providing excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the tool being idempotent in behavior (returns existing DM if same participant set), which is at odds with the annotation 'idempotentHint: false'. This contradiction reduces reliability. Otherwise, it provides error handling details but no additional behavioral traits beyond what annotations already indicate (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling). It is front-loaded with the main purpose. Although somewhat lengthy, every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all key aspects: different DM types, participant limits, idempotency (existing channel returned), error codes, and examples. An output schema exists, so return value explanation is unnecessary. The description is thorough for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for 'user_ids' by explaining 1:1, Group, and Self DM scenarios with examples. However, 'workspace_id' is not mentioned in the description; the schema already adequately describes it. Since schema description coverage is effectively high (the schema contains descriptions for both parameters), the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (or return)') and resource ('direct-message Chat channel') and specifies the limit of 15 users. It distinguishes from sibling tools 'clickup_create_chat_channel' and 'clickup_create_location_chat_channel' by mentioning they are for named or location-bound channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear guidance, including specific alternative tools to use instead. This helps the agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds cursor-based pagination details, error handling (404), and response structure (author, id, timestamp, content snippet, next_cursor), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). It is concise but includes necessary context without extraneous 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 complexity (multiple parameters, pagination) and the presence of an output schema, the description covers key aspects: purpose, usage, pagination, error handling, and basic return fields. However, it omits details about the limit parameter and response format options, which are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not describe each parameter individually; only message_id and cursor are mentioned in examples. With 0% schema description coverage from the description, it fails to add meaning beyond the existing input schema descriptions for less obvious parameters like workspace_id, content_format, and response_format.
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 replies threaded under a chat message with cursor pagination. It explicitly distinguishes from siblings by noting that for top-level messages, use clickup_get_chat_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 'When to Use' and 'When NOT to Use' sections provide explicit guidance. It says when to read a thread and when to use an alternative tool for top-level messages.
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?
Annotations already declare readOnlyHint=false (write) and destructiveHint=false. Description adds that it posts a reply, returns confirmation with reply id, and lists error codes (400, 404). It does not detail all side effects, but overall 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?
Well-structured with clear sections: purpose, when to use/not use, returns, example, error handling. Every sentence is necessary. No fluff.
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?
Covers core usage and error handling but omits explanation of optional parameters. Given the tool's complexity (many optional fields), more detail would help agents use it correctly. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Only 'message_id' and 'content' are mentioned in the example; optional parameters like 'assignee', 'followers', 'workspace_id' are not described. The description adds minimal value beyond the schema for 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 tool's purpose: 'Post a threaded reply under an existing Chat message.' It uses specific verb 'Post' and resource 'threaded reply' and distinguishes from sibling 'clickup_send_chat_message' by stating when NOT to use it.
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 ('To respond within a message's thread') and when-NOT-to-use ('To start a new top-level message — use clickup_send_chat_message'). Provides clear guidance on alternative 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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that it returns a confirmation string with view id/name/type or an error, and mentions 404 error handling. No contradictions, but could further detail side effects (e.g., whether it modifies existing data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, examples, and bullet points. It is mostly concise, though the 'Returns' and 'Error Handling' sections could be slightly more compressed. Front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the schema describes parameters well, the description covers when to use, when not, return type, and error handling. It misses explaining all optional parameters, but the schema fills that gap. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides an example with 'list_id', 'name', 'type' but does not explain all parameters in detail. The schema itself has descriptions for each property, and the example adds practical context, but the description doesn't fully cover the optional parameters' semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 view scoped to a List, with specific verb and resource. It explicitly distinguishes from sibling tools for Folder-, Space-, or Team-wide views, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to Use' and 'When NOT to Use' sections, naming alternative tools (clickup_create_folder_view, clickup_create_space_view, clickup_create_team_view) and clear conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write) and destructiveHint=false. Description adds that custom statuses are silently ignored and error codes for auth/validation, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and front-loaded. Could be slightly more concise, but every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, limitations (statuses), returns, and errors. Adequate for a creation tool with rich annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (context signal), so description must compensate. It mentions 'features' and gives an example, but does not systematically describe each parameter. The schema itself has detailed descriptions, but the tool description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new Space inside a Workspace' with specific verb and resource. Distinguishes from siblings by explicitly naming when to use folder/list tools and update_space instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to Use' and 'When NOT to Use' sections, with specific alternatives mentioned (folders/lists tools, update_space, ClickUp UI).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. Description adds that deletion is permanent and irreversible, and explains error responses (404, Error string). Could mention cascading effects, but overall adds meaningful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: overview, when to use/not, returns, example, error handling. No redundant information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core aspects: purpose, usage boundaries, example, errors. Missing potential details like permission requirements, but given annotations and output schema, it is sufficiently complete for deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but schema itself has descriptions for both parameters. The description only provides an example for channel_id and omits explanation of workspace_id. Minimal added value; does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Chat channel (Channel, DM, or location-bound). It distinguishes from sibling tools like clickup_update_chat_channel by specifying that it is for deletion, not hiding/archiving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to Use' (remove an unneeded channel) and 'When NOT to Use' (hide/archive, recommending update instead). Includes an example and error handling, offering clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by explaining content_edit_mode (replace/append/prepend), return confirmation, and error handling. Annotations indicate idempotent and non-destructive; description aligns and adds context.
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 well-structured with clear sections (summary, edit mode, when, returns, examples, error handling). Slightly verbose but front-loaded with core 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?
Covers main parameters and behavior. With output schema present, return value explanation is adequate. Missing details on workspace_id and content_format, but overall 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?
With schema description coverage at 0%, description partially compensates by explaining name, subtitle, content, and content_edit_mode. However, workspace_id and content_format are not mentioned in description, relying on schema which counts as no coverage.
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 'Update a Doc page's title, subtitle, and/or content' with specific verb and resource. Distinguishes from sibling clickup_create_page by stating when NOT to use this 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?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, naming clickup_create_page as alternative. Also explains content_edit_mode behavior and gives examples.
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?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds key behavioral details: negative duration for running timers, 'No timer' message, and output format options, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections and front-loaded purpose. Each sentence adds value, though slightly longer than minimal. 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 usage, behavior, return details, and error scenarios. With good annotations and sufficient parameter documentation, it provides a complete understanding for the agent. Output schema existence is noted but not needed given 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?
Input schema already provides descriptions for all parameters (team_id, assignee, response_format). Description adds examples and error handling but does not significantly extend parameter meaning. Schema coverage is effectively high, so 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 tool retrieves the currently running time entry for a user. It uses a specific verb and resource, and distinguishes from siblings like clickup_get_time_entries and clickup_start/stop_time_entry.
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 (before starting or stopping a timer) and when not to use (for historical entries, use clickup_get_time_entries). Also covers error handling for 403 permission issues.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds significant context: the API endpoint, that renaming changes the tag definition itself affecting all entries, returns a confirmation string with old/new names, and error handling for 404. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (purpose, usage, returns, examples, error handling). It is informative without being verbose, though slightly longer than necessary. Good front-loading.
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?
Description covers all key aspects: purpose, when to use/not use, behavioral effect, return value, example usage, and error handling. Given the complexity (5 parameters, output schema exists), it is fairly 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 full descriptions for all parameters, so schema description coverage is high. Description reiterates the purpose of 'name' and 'new_name' and mentions colors, but adds little 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 tool renames a time-entry tag and sets its colors across the whole Workspace, using specific verb and resource. It distinguishes from sibling tools like clickup_add_time_entry_tags and clickup_remove_time_entry_tags by contrasting their actions on specific entries vs. tag definition change.
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' sections provide clear context: use for fixing typos or standardizing colors; do not use to add/remove tags from specific entries. References sibling tools for the alternative 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?
Annotations indicate it's a write operation (readOnlyHint=false) and non-idempotent, but the description adds valuable behavioral context: only task-to-task links are supported, returns a confirmation naming both tasks, and explains 404 error handling. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, when to use/not, returns, examples, error handling). Every sentence is informative and no word is wasted, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description wisely summarizes the return type without over-explaining. It covers error handling and constraints (task-to-task only). However, it omits details like idempotency or rate limits, but these are partially covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (100% coverage despite context signal), so the description adds limited extra semantic value. It covers the non-blocking nature and error conditions but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Link two tasks with a non-blocking "related to" association', specifying the action, resource, and linkage type. It distinguishes itself from siblings like clickup_add_dependency by emphasizing the non-blocking nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear context for when this tool is appropriate and directing the user to clickup_add_dependency for completion order enforcement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write operation (readOnlyHint=false). Description adds concrete return format (id, hist_id, timestamp) and error handling (404 meaning). Does not detail side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, then logically organized into endpoint, when to use, returns, example, and error handling. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context with legacy vs new API distinction, return format, error handling, and example. Could be more explicit about response structure but text description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides descriptions for all parameters (100% coverage). Description includes an example but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it posts a comment into a Chat view and distinguishes from the newer chat message tool (clickup_send_chat_message). Clear verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Dedicated 'When to Use' and 'When NOT to Use' sections with explicit alternative tool name and scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent. The description adds details on return format (confirmation string with optional id) and error handling (404, 400), supplementing annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and examples, though slightly verbose. Front-loaded with purpose, but every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, alternatives, errors, and return format. With a simple schema and output schema provided, the description is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover parameter meanings. The description's examples illustrate usage but do not add significant semantic depth beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new line item to an existing checklist,' which is a specific verb+resource. It distinguishes from siblings like clickup_create_checklist by focusing on adding an item to an existing checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear context, including naming the alternative tool clickup_create_checklist for creating the checklist itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and idempotent. The description adds context about permanence, inclusion of replies, confirmation response, and error behavior (returning an 'Error ...' string). This goes beyond the annotations and provides valuable behavioral insights.
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 well-structured with clear sections, no redundant sentences, and front-loaded with the core purpose. Every section earns its place 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?
The description covers the main aspects: purpose, usage guidance, error handling, and return type. It mentions deleting replies, which is not obvious. However, it does not discuss the optional workspace_id parameter or permissions, but the schema fills some gaps. Given the tool's simplicity and the presence of an output schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema providing descriptions for both parameters (message_id and workspace_id), the tool description only mentions message_id in the example and does not explain workspace_id. Since schema description coverage is 0% (meaning the description does not cover parameters), it fails to compensate for the missing parameter info. The example helps but is insufficient for complete 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 verb 'delete' and the resource 'Chat message' with the scope 'and its replies'. It distinguishes itself from the sibling tool 'clickup_update_chat_message' by explicitly stating when not to use it and suggesting the alternative.
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 'When to Use' and 'When NOT to Use' sections, including the exact alternative tool. It also covers error handling with a specific HTTP status code and return format, giving complete 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?
Annotations mark as destructive and idempotent. Description adds that the deletion is permanent, returns a confirmation string, and clarifies that a 404 means the checklist may already be deleted. This complements the annotations without contradiction.
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 well-organized with clear sections (main action, when to use, when not, returns, error handling). It is efficient but could be slightly more concise without losing clarity.
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 parameter, destructive, idempotent), the description fully covers purpose, usage guidelines, return value, and error handling. The existence of an output schema reduces the need to detail return values.
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 `checklist_id` has a schema description ('ID of the checklist to delete'). The description text does not add any additional semantic detail 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 opens with 'Permanently remove a checklist (and all of its items) from its task,' clearly stating the verb, resource, and scope. This distinguishes it from siblings like `clickup_delete_checklist_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?
Explicitly states when to use ('The checklist is no longer needed') and when not to use ('To remove a single item, use `clickup_delete_checklist_item` instead'). Also includes error handling context for 404.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: lightweight outline, returns tree of names/ids, error handling (404). Does not contradict 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?
Well-structured with clear sections (purpose, when to use, returns, examples, errors). Front-loaded with essential info, 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?
Given the tool's simplicity, output schema exists, and annotations cover safety, the description adequately explains return values (tree of names/ids) and error behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate for parameter details. It only provides a single example showing doc_id and max_page_depth, but does not explain workspace_id, response_format, or parameter semantics beyond what the schema already provides. The schema itself has good descriptions, but the description fails to add 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 'List a Doc's page tree (titles and ids only, nested — no content)', specifying the verb (list), resource (Doc page tree), and scope. It distinguishes from siblings like clickup_get_doc_pages (which fetches content) and clickup_get_page (single page).
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 'When to Use' (see structure, grab page IDs cheaply) and 'When NOT to Use' (read content, with alternatives named). This directly guides 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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional disclosure is lower. The description adds valuable context: it returns title, subtitle, content (markdown default), mentions truncation for large Docs, and covers error handling (404). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with distinct sections (purpose, usage guidelines, returns, example, error handling). Every sentence earns its place, and the 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 that an output schema exists and the input schema is rich, the description covers key aspects: the core functionality, behavior for large Docs, error handling, and an example. It lacks detail on optional parameters like workspace_id and max_page_depth, but those are well-documented in the schema. Overall, it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters, so the description adds limited extra value. It includes an example with doc_id and content_format, which is helpful but not essential. The schema coverage being 100% effective (despite signal saying 0% in description text) sets a 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 (Fetch), the resource (Doc's pages with content), and explicitly distinguishes from siblings like clickup_get_page and clickup_get_doc_page_listing, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to Use' and 'When NOT to Use' sections with specific alternative tools, giving the agent clear decision criteria for selecting this tool over others.
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?
Annotations already declare readOnlyHint and destructiveHint, so the description's main behavioral additions are the return format options, pagination behavior (windowing, has_more), and error handling for 404. These add useful context beyond annotations. No contradictions found.
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 well-structured with distinct sections (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). Every sentence serves a purpose, though it could be slightly more concise. Front-loading is good.
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 description covers all essential aspects: purpose, usage alternatives, pagination behavior, error handling, and return format. Given the presence of an output schema, it does not need to detail return values. The description is complete 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?
The input schema already provides descriptions for all parameters, so the tool description does not need to repeat them. It adds example usage but does not elaborate on parameter semantics beyond the schema. Baseline 3 is appropriate given schema coverage.
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 the Lists that belong to a Folder.' It also distinguishes itself from sibling tools by specifying when not to use it (use clickup_get_folderless_lists or clickup_get_list instead), 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 provides explicit 'When to Use' and 'When NOT to Use' sections, including specific alternative tool names. This gives the agent clear guidance on when to invoke this tool versus others.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral context: inheritance from Workspace, return format (markdown vs JSON), and error handling. This extra context justifies a score above baseline but not a 5 since annotations already do significant work.
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 well-structured with clear sections (purpose, behavior, usage, returns, example, errors). It is concise with no wasted 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?
Given the output schema exists, the description explains what is returned and covers error scenarios. It differentiates from sibling tools adequately. A score of 4 reflects that while thorough, it could optionally mention pagination or limits, but it's sufficient 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?
The input schema provides descriptions for all parameters (space_id, response_format, include_applied_objects). The description adds error codes related to parameters but does not significantly enhance understanding beyond what the schema 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 verb 'List' and the resource 'Custom Fields available at a Space scope.' It distinguishes from siblings by noting inheritance from Workspace and explicitly tells when not to use this tool, directing to clickup_get_list_custom_fields.
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?
There are explicit 'When to Use' and 'When NOT to Use' sections, providing clear context. It names an alternative tool (clickup_get_list_custom_fields) for a different use case, helping the agent decide correctly.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by noting Enterprise plan restriction (403 on other plans), error handling for 403 and 404, and return format details.
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?
Well-structured with clear sections (note, when to use, returns, examples, error handling). Concise but could be slightly shortened without losing 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?
Comprehensive for a read-only lookup tool with 4 parameters and output schema (described returns). Covers plan restrictions, error handling, and usage guidance.
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 covers all parameters with descriptions, so baseline is 3. Description does not add much beyond schema, except mentioning the params example. No contradiction.
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 looks up a single Workspace member's profile, role, and admin status. Distinct from sibling tools like clickup_get_list_members and clickup_get_guest.
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' and 'When NOT to Use' sections, including specific alternatives (clickup_get_list_members, clickup_get_task_members, clickup_get_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?
Annotations already provide hints (readOnlyHint=false, idempotentHint=true). The description adds value with error handling (404) and implicit tag creation behavior. However, it does not fully describe idempotency implications or other side effects, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, endpoint, siblings, usage, returns, examples, error handling). It is concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and thorough error handling, the description covers all essential aspects. It is complete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has detailed descriptions for each parameter, so the tool description does not need to repeat them. However, with 0% coverage from the description, it offers only an example that ties parameters together. This is adequate but not excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply tags to time entries), specifies the endpoint, and distinguishes from sibling tools (remove and rename). It also provides usage context for bulk-tagging and implicit tag creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (bulk-tagging, new tag) and when not to use (single entry editing via clickup_update_time_entry), offering a clear alternative. This meets the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return format (confirmation or error string), error handling (404, 400), and lack of folder parent. Annotations are sparse (no readOnlyHint, destructiveHint), so description adds meaningful behavioral context, though no mention of side effects or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded with purpose, and concise without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: purpose, usage conditions, alternatives, return format, examples, error cases. Output schema exists but description aligns with it. Complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides examples for space_id, name, and optional status but does not explain other parameters (content, assignee, due_date, etc.). Input schema already has detailed parameter descriptions, so description adds marginal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 list directly in a space without a parent folder, using specific verb and resource. It distinguishes from sibling tools like clickup_create_list and clickup_create_list_from_template_in_space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections with named alternatives (clickup_create_list, clickup_create_list_from_template_in_space) provide clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, destructiveHint=false). Description adds return type (confirmation string with id, name, type, or error string) and error handling (404 meaning wrong folder_id). Does not contradict annotations. Could mention any side effects, but creation tools typically have minimal side effects beyond creating the view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with clear sections: purpose, when to use, when not to use, returns, example, error handling. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a comprehensive schema and existing annotations, the description covers usage context, error cases, and return format. Output schema is noted as present, so return details are sufficiently covered. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (schema_description_coverage is high, though context says 0% it appears descriptions are present). The description provides a concrete example of required parameters (folder_id, name, type). This adds value over schema alone but does not detail optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a task or page view scoped to a Folder.' Differentiates from sibling tools by specifying when NOT to use and naming alternatives (clickup_create_space_view, clickup_create_team_view, clickup_create_list_view).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools for other scopes. This gives clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds context on grouping key results, return value, and error scenarios, but does not elaborate on open-world implications or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized and concise: purpose, relationship to other tools, usage guidance, return type, example, and error handling, all in a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description covers all necessary context: action, usage, alternatives, errors, and an example, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters, and the function description adds an example but no additional semantic meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'Goal' in a Workspace, and distinguishes from related tools like clickup_create_key_result and clickup_update_goal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections, including specific alternative tool names and error handling codes, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains inheritance of Folder statuses, clarifies that the 'status' parameter is a color not a task status, details error handling, and specifies the return format. It does not contradict annotations, which are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, inheritance, when/not, return, examples, and errors. It is informative without being overly verbose, though some sentences could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidelines, parameter semantics, return type, and error codes. It lacks explicit mention of permissions or rate limits, but these are not critical for this simple creation tool and are implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates by providing examples and clarifying parameter behavior (e.g., status as color, content vs. markdown_content), adding value beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 List inside a Folder, and distinguishes it from sibling tools like clickup_create_folderless_list and clickup_create_list_from_template_in_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, referencing concrete scenarios and alternative tools, providing excellent guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly, non-destructive, and openWorldHint. The description adds return type (confirmation string or error) and error scenarios, but does not detail mutation behavior or side effects beyond creation. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) with no redundancy. Every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single required parameter with nested fields, an output schema exists, and annotations are provided, the description fully covers usage context, return values, and error handling, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for each parameter are already detailed (e.g., 'Display name for the new view'). The description provides a brief example but does not add substantial meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a task or page view scoped to a Space' which is a specific verb-resource combination. It also distinguishes from sibling tools like clickup_create_team_view, clickup_create_folder_view, and clickup_create_list_view by explicitly stating when not to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'When to Use' and 'When NOT to Use' sections with explicit alternatives for workspace-wide or folder/list-scoped views. Also includes error handling advice for 404 and 403 errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: return format (confirmation string with id, hist_id, timestamp) and error handling for 404/403. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, endpoint, when to use, when not to use, returns, examples, error handling). Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of annotations and schema, the description fully covers usage context, return values, error cases, and examples. It is complete for effective agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters, so the tool description adds little beyond mentioning assignee/group_assignee for action items. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a comment to a task' and specifies the API endpoint. It distinguishes from sibling tools like clickup_create_threaded_comment and clickup_create_list_comment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (feedback, questions, handoffs, action items) and when not to use (threaded replies, list/chat view comments), naming alternative tools. Provides excellent decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds error handling details (404 response) and mentions the reaction is sent as a path segment, but does not discuss rate limits or other side effects. Adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, when to use, when not to use, returns, examples, error handling). Each sentence is purposeful and concise, with 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 that an output schema exists, the description appropriately includes a brief 'Returns' statement. It covers error scenarios (e.g., 404) and usage guidelines. For a simple delete operation, this is complete and contextual.
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 describes all parameters with clear descriptions. The description provides an example and error handling but does not add new semantic meaning beyond what schema states. Baseline is 3 due to high schema coverage.
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 'Remove an emoji reaction from a Chat message.' It uses a specific verb and resource, and distinguishes from the sibling tool 'clickup_add_chat_reaction' by explicitly contrasting the use case.
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 sections 'When to Use' and 'When NOT to Use', guiding the agent to only undo reactions and not add them, with a clear alternative tool reference.
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?
Annotations already declare destructiveHint: true, readOnlyHint: false, idempotentHint: true. The description adds value by specifying the return format (confirmation string with deleted item id) and error handling for 404, which are beyond the 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?
The description is extremely concise, with clear sections for purpose, usage guidance, returns, and error handling. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description covers what the tool does, when to use it versus alternatives, what the output looks like (confirmation string), and common error scenarios. This is complete given the tool's simplicity and the presence of an 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?
The input schema already provides descriptions for both required parameters ('ID of the parent checklist', 'ID of the checklist item to delete'). The description does not add any additional meaning or guidance on parameter 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 the action: 'Remove a single line item from a checklist'. It specifies the resource (checklist item) and distinguishes from deleting the whole checklist with the parenthetical 'the checklist itself stays'.
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' and 'When NOT to Use' sections. It details that the tool should be used when an individual to-do is irrelevant but the checklist should remain, and directs to `clickup_delete_checklist` for removing the entire checklist.
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?
Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds that deletion is permanent, returns a confirmation string, and specifies error handling (404). Does not contradict 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?
Description is concise and well-structured with sections for purpose, usage, returns, and error handling. 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?
Given the simple operation (delete with one param) and existing annotations plus output schema, the description provides complete guidance including alternatives and error cases.
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?
Single parameter key_result_id is well-described in the schema with 'UUID to permanently delete'. Description does not add additional semantics beyond the schema, and schema coverage is presumably high, 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?
Clearly states the tool permanently deletes a key result from its goal. Explicitly distinguishes from sibling tool clickup_delete_goal by specifying it removes a target while keeping the parent goal.
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 when-to-use (removing a target that no longer applies) and when-NOT-to-use (deleting the whole goal), with an alternative tool named (clickup_delete_goal).
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?
Annotations already indicate destructive and idempotent. Description adds return confirmation and error handling (404 for non-existent link or task). Adds context beyond annotations without contradiction.
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 concise with clear sections: summary, when to use, when not, returns, examples, error handling. Every sentence is useful and 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 tool complexity (simple delete operation) and presence of output schema, description covers purpose, usage, error handling, and example adequately. 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 descriptions already cover parameters well (task_id, team_id, links_to, custom_task_ids). Description provides an example but does not add new semantic 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?
Description clearly states 'Remove a related to link between two tasks', which is a specific verb+resource. It distinguishes from siblings like clickup_delete_dependency and clickup_add_task_link.
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 (undo association from clickup_add_task_link) and when not (use clickup_delete_dependency for blocking dependencies). 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?
Annotations (destructiveHint=true, idempotentHint=true) are complemented by description stating 'permanently delete' and return type. Adds context about scope (only view, not parent) and error handling. Could mention idempotency implications, but overall 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?
Well-structured with clear sections: purpose, when to use/not use, returns, examples, error handling. Front-loaded with key action. 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?
Covers return value (confirmation or error string) and error handling (404). With output schema existing, description is sufficient for a simple delete tool with one parameter.
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 schema description 'View id to delete.' Tool description adds little semantic value beyond the schema, but includes an example usage ('params = {"view_id": "abc123"}') which aids understanding. Adequate but not exceptional.
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 'Permanently delete a task or page view' and distinguishes from sibling delete tools by specifying it only removes the view, not the parent container. Examples of view types (dashboard/board/etc.) further clarify 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?
Explicit when-to-use and when-NOT-to-use sections. Tells when to use (removing a view no longer needed) and when not to use (deleting underlying container) with pointers to other tools. Includes error handling for 404.
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 discloses permanent deletion and the lack of a pause feature, reinforcing the destructiveHint annotation. It also specifies the return type (confirmation) and error handling. However, it does not explicitly address idempotency as hinted by idempotentHint, though the example and error handling imply non-idempotent behavior on unknown IDs.
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 well-structured with clear sections (summary, when to use/not use, returns, example, error handling). It is concise yet comprehensive, with 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?
For a delete operation, the description covers all key aspects: purpose, usage guidance, return value, example, and error handling. Annotations already convey destructive and idempotent hints, so no additional behavioral 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 describes the webhook_id parameter as a UUID. The description adds an example value but does not provide significant additional meaning beyond what the schema offers. With schema coverage effectively 100% (the single parameter has a description), the description's contribution is minimal.
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 webhook and stops event delivery. It distinguishes itself from other tools by explicitly noting there is no pause functionality and referencing clickup_create_webhook as the alternative.
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 'When to Use' and 'When NOT to Use' sections. It advises against using it for temporary pausing and suggests recreating with clickup_create_webhook 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?
Annotations indicate non-readonly (write operation), non-destructive, and idempotent. The description adds behavioral context by stating it returns a confirmation string with the checklist's name and ID, and notes error handling (404 for missing checklist_id). This complements without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using clear section headings (When to Use, When NOT to Use, Returns, Examples, Error Handling). Every sentence adds value, and the purpose is 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 that an output schema exists (context signal), the description adequately covers return type, error handling, and usage examples. The 3 parameters are well-explained in the schema and examples. Complete for this 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?
The input schema already provides descriptions for all parameters (name, position, checklist_id). The description adds example usage but no new semantic details beyond the schema. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renames and/or repositions a checklist among a task's other checklists. The verb 'Rename' and 'reposition' combined with 'checklist' make the action explicit. It distinguishes from sibling tool 'clickup_edit_checklist_item' which handles individual items.
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 includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear context for when to invoke this tool versus alternatives. It names the specific sibling tool for handling individual items.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds return fields and error handling specifics (404 returns Error string). Does not contradict annotations and provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, when to use/not use, returns, example, error handling. Every sentence adds value. Front-loaded with main action. Length is appropriate 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?
Given annotations and presence of output schema (context signals), description covers purpose, usage, error handling, and return fields. No gaps for a single-item read operation. Complete and informative.
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 describes all parameters well (e.g., channel_id: 'Id of the Channel to fetch.'). Description adds an example usage for channel_id but no additional semantics for other parameters. Schema coverage is high, 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 a single Chat channel's metadata by id'. It specifies the exact resource (chat channel metadata) and action (fetch by id). Differentiates from siblings: lists clickup_get_chat_channels for listing and clickup_get_chat_messages for 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?
Explicit 'When to Use' and 'When NOT to Use' sections provide clear context. States to use for confirming channel type/visibility/etc., and not for listing or reading messages, with specific alternative tool 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?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false. The description adds context: followers receive notifications but are not members, cursor-pagination, and error handling (404). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections (summary, clarification, When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). Front-loaded with purpose. 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's complexity (list with pagination), the description covers purpose, alternative, pagination mechanics, examples, and error handling. Output schema exists, so the return summary 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 description coverage is 0%, so description must compensate. It adequately explains channel_id, cursor, and limit through examples and pagination section. However, workspace_id and response_format are not described. Partial coverage.
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 the users following a Chat channel' – a specific verb and resource. It further distinguishes from the sibling tool 'clickup_get_chat_channel_members' by noting followers are not necessarily members.
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' sections. The 'When NOT to Use' directly names an alternative tool (clickup_get_chat_channel_members) for a different purpose.
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?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds workspace-specific uniqueness of subtype IDs, error handling for unknown workspaces (404), and error output format ('Error ...' string), providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections: purpose, usage, when to use/not, returns, examples, error handling. Each sentence adds value; no fluff. Front-loaded with main 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 list tool with good annotations and output schema, the description is complete: covers all necessary aspects (purpose, usage, examples, error handling, integration with other tools). 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?
The input schema provides full descriptions for all parameters (comment_type, workspace_id, response_format), so the description does not need to add much. It mentions usage of subtype IDs in other tools but does not enhance parameter meaning beyond 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?
Clearly states listing workspace post subtype IDs with specific examples (Announcement, Discussion, Idea, Update) and distinguishes from sibling tools by explaining its role in preparing subtype IDs for post 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?
Explicitly specifies when to use (before sending post-type chat messages) and when not to use (for plain messages), with direct references to related tools like clickup_send_chat_message.
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?
Annotations already declare read-only, idempotent, non-destructive. Description adds return fields and error handling format, but does not disclose additional behavioral traits like authentication or rate limits. No contradiction.
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?
Well-structured with clear sections, front-loaded main purpose, no redundant sentences. Efficient and easy to parse.
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, usage constraints, return value description, error handling, and example. Given annotations and schema, the description is complete for this 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 already provides descriptions for all parameters. Description only adds an example for doc_id but does not elaborate on workspace_id or response_format. No added 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 it fetches Doc metadata only, distinguishing from sibling tools that read text or list pages. Verb 'Fetch' with specific resource and 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 lists when to use (confirm parent location/creation details) and when not to use (with alternative tool names given). Also provides error handling 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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds the HTTP method (GET), return types (markdown/JSON/error), error handling for 404, and the specific API endpoint. This adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections: summary, API call, usage guidelines, returns, examples, error handling. Every 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?
For a read-only single-item fetch tool with annotations and output schema, the description covers purpose, when to use, return format, error handling, and example. It is complete and leaves no major 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 already has descriptions for both parameters (folder_id: 'The Folder id to fetch', response_format: 'Output format'). The tool description provides an example usage and mentions response format but does not add significant new 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?
The description clearly states 'Fetch one Folder, including its Lists and status workflow' which is a specific verb+resource. It also distinguishes from sibling tool 'clickup_get_folders' by the scope (single vs multiple).
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 explicitly provides 'When to Use' (inspect a specific Folder's details before updating) and 'When NOT to Use' (browse all folders, use clickup_get_folders instead), offering clear guidance on 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?
Annotations already convey read-only, idempotent, non-destructive behavior. Description adds the API endpoint, inheritance behavior, output format options, and specific error responses (404, 401/403). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: purpose, details, usage guidelines, return format, example, error handling. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and an output schema, the description provides sufficient behavioral context, usage differentiation, and error handling. The tool is fully understandable for correct selection and invocation.
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?
Description includes an example and mentions the response_format usage, but input schema already describes all parameters with detailed descriptions. The additional value is marginal; schema covers semantics well.
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 Custom Fields at Folder scope, includes inherited fields, and explicitly differentiates from sibling tool clickup_get_list_custom_fields. The verb 'List' and resource 'Folder Custom Fields' with scope details provide high specificity.
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 'When to Use' and 'When NOT to Use' sections, advising to use an alternative for task-specific fields. Also includes error handling guidance for common HTTP status codes.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining client-side pagination (limit/offset), return content (folder list with counts), and error handling for 404. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for overview, when to use/not use, returns, pagination, examples, and error handling. Every sentence is informative, no fluff, and front-loaded with the 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 the presence of output schema and comprehensive annotations, the description provides thorough guidance: usage context, relationship to sibling tools, pagination behavior, example parameters, and error handling. It is fully complete for an agent to understand and use the 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?
The input schema already contains descriptions for all parameters (space_id, archived, limit, offset, response_format), providing sufficient context. The description does not add additional parameter-level meaning, 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 'List the Folders in a Space' with the specific API endpoint, and distinguishes from sibling tool `clickup_get_folder` by noting that this tool returns each Folder's task/list counts and `override_statuses` flag.
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' sections provide clear guidance: use for discovering folders before creating/updating, or checking status overrides; avoid for full folder details (use `clickup_get_folder`) or for folderless lists (use a yet-unavailable 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?
Annotations already declare readOnly and idempotent hints. Description adds that the tool returns a markdown/JSON list or error string, explains client-side pagination with limit/offset, and covers error handling for 404. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with clear sections for purpose, usage, returns, pagination, examples, and error handling. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description adequately covers the return type and possible error. Pagination and error handling are explained, making it complete for a list 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?
Input schema has detailed descriptions for all parameters (limit, offset, team_id, response_format) covering their meaning and default values. The description adds no significant extra meaning beyond what the schema already provides, so baseline at 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?
Clearly states 'List the Folder templates available in a Workspace' with specific verb and resource. Distinguishes from sibling tool clickup_get_folders by explicitly stating when not to use. Also links to clickup_create_folder_from_template.
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' sections provide clear guidance on appropriate context and alternatives, including naming the sibling tool clickup_get_folders for actual folder listing.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by specifying the return format (Markdown or JSON), listing returned fields (id, name, type, parent, required_views), and noting error handling (404 for wrong folder_id). This additional context is helpful beyond the 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?
The description is concise and well-structured. It leads with the purpose, then has clearly labeled sections (When to Use, When NOT to Use, Returns, Examples, Error Handling). Every sentence serves a purpose, and there is no redundancy or unnecessary 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 the presence of an output schema, the description appropriately does not elaborate on return values beyond what is needed. It covers the return format, key fields, error cases, and provides a concrete example. For a read-only list tool with siblings, it provides complete context for an agent to decide when and how to use it.
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 descriptions for both parameters (folder_id: 'Folder id to list views for.'; response_format: 'Output format.'). The tool description adds minimal additional meaning; it only gives an example using folder_id. Given that schema coverage is 0% (meaning no parameter descriptions in the tool description text itself), the description does not compensate significantly, but the schema fills the gap.
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 the task and page views available for a Folder.' This provides a specific verb ('list') and resource ('views available for a Folder'). It also distinguishes from sibling tools by specifying when not to use it (for other view levels) and pointing to alternative 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 includes 'When to Use' and 'When NOT to Use' sections. It explains that this tool is for discovering existing Folder-level views before calling other tools, and it excludes Everything-, Space-, or List-level views with references to specific sibling tools, providing clear 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?
Annotations already cover readOnlyHint and idempotentHint. The description adds context about response scope (excludes group/inherited access) and error handling, but does not contradict 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?
Well-structured with clear sections, front-loaded purpose, and no unnecessary sentences.
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 description covers purpose, usage guidelines, return format, examples, and error handling, making it complete for this simple 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?
Context indicates 0% schema description coverage, but the description provides examples and explains list_id implicitly. Response_format is not elaborated beyond the schema, leading to 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 the tool lists workspace members with direct access to a list, and distinguishes from siblings like clickup_get_task_members and clickup_get_user_groups.
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' sections with specific alternatives provided, guiding selection effectively.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the return content (title, subtitle, markdown) and error handling (404), which enhances transparency beyond the 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?
The description is well-structured with clear sections (main action, usage, returns, examples, error handling). It is concise, front-loading the core purpose, and 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?
Given the presence of an output schema and 5 parameters, the description adequately covers return format, example usage, and error scenarios. It is complete for an agent to understand and invoke the tool 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 provides thorough descriptions for all parameters, so schema coverage is effectively high. The description does not add further meaning to the parameters beyond what is already in the schema, resulting in a 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 'Fetch one page of a Doc, including its content.' The verb 'Fetch' and resource 'page' are specific, and the distinction from sibling `clickup_get_doc_pages` is explicit.
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 includes explicit 'When to Use' and 'When NOT to Use' sections, directly telling the agent when to call this tool and when to use `clickup_get_doc_pages` instead, providing clear 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds details on return content (status workflow, ClickApp toggles) and error handling (404 meaning). This provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with well-organized sections (When to Use, When Not, Returns, Examples, Error Handling). Every sentence adds value and is front-loaded with the main 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?
For a simple get tool with one required parameter and annotations covering safety, the description is complete. It covers return format, error handling, and usage context. 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?
The schema has basic descriptions for both parameters, but the description does not add significant additional semantics beyond schema. The example provides some context for space_id. Adequate but not exceptional.
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 'Fetch full detail for a single Space' with a specific verb and resource. It distinguishes from sibling tools like clickup_get_spaces by specifying it's for a single space, not enumeration.
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 (inspecting statuses before update, confirming existence) and when not to use (enumerate all spaces, directing to clickup_get_spaces). This is excellent 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?
Annotations already provide read-only, idempotent, non-destructive hints. Description adds return format (markdown/JSON), fields included, and error handling for 404. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and example. Concise yet informative, 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, when to use, alternatives, return format, example, and error handling. Fully complete given output schema and annotations.
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 descriptions for both parameters. Description adds minimal extra meaning (example usage, output format impact), baseline score 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 'List the task and page views available for a Space.' Uses specific verb and resource, and distinguishes from sibling tools by mentioning other view levels.
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 (discovering views before other operations) and when not to use (other levels), with alternatives like clickup_get_team_views.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: negative duration means timer is still running, and error handling for 404. This supplements the annotations well without redundancy.
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 well-structured with clear sections: purpose, endpoint, when to use/not use, returns, examples, error handling. Each sentence adds value, and the length is appropriate for the complexity.
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, usage guidance, behavioral details (negative duration), return format, error handling, and example. With annotations and an output schema presumably present, the description is complete for decision-making.
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 descriptions for each parameter. The description adds little parameter-level detail beyond mentioning team_id and time_entry_id in the endpoint and noting response_format in the example. Given schema coverage is high (schema has descriptions), the description's added value is marginal.
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 'Fetch one time entry by id', specifies the verb (fetch) and resource (time entry by id). It distinguishes from siblings like clickup_get_time_entries, clickup_get_time_entry_history, and clickup_get_running_time_entry by explicitly naming them in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has dedicated 'When to Use' and 'When NOT to Use' sections. States use when you already have a time_entry_id, and provides clear alternatives for list, history, and running timer scenarios. Also lists prerequisites (id from list or create).
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?
Annotations indicate the tool is read-only, idempotent, and non-destructive. The description adds context about the HTTP method (GET), the variability of response fields, and output format options, which are behavioral traits not covered by annotations. It also explains error handling, enhancing 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 well-structured with headings for use cases, return values, examples, and error handling. Every sentence adds value, and there is no redundant or verbose language.
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 (read-only history retrieval with a few parameters), the description covers purpose, usage, parameters, output format, and error handling comprehensively. The existence of an output schema does not detract, and the description properly acknowledges the upstream inconsistency.
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?
Despite 0% schema description coverage, the description explains the key parameters: it gives an example with `team_id` and `time_entry_id`, mentions the default for `team_id` from environment variable, and alludes to `response_format` via output format discussion. This adds meaning beyond the bare schema, but lacks explicit mention of the `response_format` parameter name.
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 'View the list of changes made to a time entry', which is a specific verb+resource. It distinguishes from the sibling tool `clickup_get_time_entry` by noting that the latter is for reading current state, making the purpose clear and unique.
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 sections 'When to Use' (auditing changes) and 'When NOT to Use' (to read current state, referencing `clickup_get_time_entry`) provide clear usage guidance. Error handling for 404 is also included, adding to the guidelines.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds return value details (plan name and numeric id) and error handling (404, 401), providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling). Every sentence is informative 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?
Given the simple nature of the tool, the description covers purpose, usage guidelines, return values, examples, and error handling. Adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (team_id and response_format) with defaults and description. Description adds examples but no additional param semantics. Baseline score due to schema coverage.
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 reports the current subscription plan of a Workspace. Distinguishes from sibling clickup_get_workspace_seats by explicitly noting it's not for seat usage.
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 'When to Use' and 'When NOT to Use' sections. Advises checking Enterprise status before calling Enterprise-only endpoints and names alternative sibling tool for seat 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?
Annotations already indicate destructiveHint=true, but the description adds specifics: returns a confirmation string or error, and details on error codes (403 for plan, 404 for missing IDs). This goes beyond the 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?
The description is well-structured with clear sections: purpose, plan note, when to use, when not to use, returns, example, and error handling. It is concise and 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?
Given the presence of an output schema (as indicated by context signals), the description covers returns, error handling, plan restriction, and provides an example. It is fully complete for a destructive removal 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?
The input schema already has descriptions for all three parameters (guest_id, folder_id, include_shared), so schema_description_coverage is 100%. The description does not mention include_shared, but since the schema is sufficient, 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 starts with a clear verb+resource: 'Revoke a guest's access to a Folder.' It distinguishes from siblings like clickup_remove_guest_from_list and clickup_remove_guest_from_task by specifying when not to use them.
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' and 'When NOT to Use' sections with alternative tool names, making it easy for the agent to choose the correct 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?
Annotations already declare destructiveHint=true and idempotentHint=true. Description adds critical context: Enterprise plan restriction (403), error codes (403, 404), and return type (confirmation/error string). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet sections, front-loaded main action, and includes examples and error handling. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and schema, the description covers purpose, usage boundaries, return value, error handling, and plan limitation. Complete for a mutation 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?
Input schema has full description coverage for all 5 parameters, so baseline is 3. The tool description does not add additional parameter meaning beyond what 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?
Description clearly states 'Revoke a guest's access to a single task' with specific verb and resource. It distinguishes from sibling tools like clickup_remove_guest_from_workspace and clickup_add_guest_to_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' and 'When NOT to Use' sections, including a concrete alternative (clickup_remove_guest_from_workspace) for the wrong case.
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?
Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds valuable context: partial update behavior ('send only the fields you want to change'), content_format interpretation, and location rebind requirements (both location_id and location_type needed). 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?
Well-structured with clear sections: functionality, when to use/not use, returns, examples, error handling. Front-loaded with purpose, no wasted sentences.
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 important aspects: optional fields, location rebind, content format, return confirmation, error codes. Output schema exists, so return description suffices. Siblings provided for 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 0%, but description adds meaning beyond schema descriptions: explains partial updates, mutual dependency of location_id and location_type, and content_format effect. However, schema already documents each parameter; description complements but doesn't fully compensate.
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 it updates a chat channel's attributes (name, description, topic, visibility, location). It distinguishes from sibling clickup_delete_chat_channel, which is explicitly mentioned in 'When NOT to Use'.
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, update topic/description, toggle visibility) and when not to use (delete, referencing the sibling tool). Provides examples and error handling.
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 REST API call (PUT /comment/{comment_id}), return type, and error codes (404, 403). Annotations provide readOnlyHint false and destructiveHint false; description adds API details and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized: overview, API call, usage guidance, return, example, error handling. All sentences are informative and 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?
Covers all necessary aspects: purpose, when/not to use, error handling, return value. An output schema exists, so return description 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 already has detailed descriptions for all parameters (e.g., 'comment_id', 'comment_text', 'resolved'). The description example shows usage but doesn't add 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?
The description clearly states the tool edits a comment's text, reassigns it, or toggles resolved state. It distinguishes from siblings like clickup_delete_comment and clickup_create_threaded_comment.
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' sections with examples and alternatives (e.g., deletion or threaded replies).
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?
Annotations already indicate non-readOnly non-destructive idempotent. Description adds that assignees are changed incrementally via add/remove lists, mentions the PUT endpoint, and lists common error codes. No contradiction.
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?
Well-structured with sections for usage, returns, examples, and errors. A few extra details but no wasted sentences. Could be slightly more concise but remains 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 the complex input schema, output schema availability, and annotations, the description covers usage guidance, error handling, and key behavioral quirks. Lacks explicit mention of rate limits or authentication, but those are implied by ClickUp context.
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 descriptions for all parameters. Description explains assignee additive behavior beyond schema, points out custom_fields reliability issue, and provides usage examples. Adds value despite not covering every parameter individually.
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 'Update fields on an existing task' and lists specific fields like name, description, status, etc. It distinguishes from sibling tools by explicitly naming when to use create_task, move_task, and set_custom_field_value instead.
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 'When to Use' and 'When NOT to Use' sections with clear alternatives: create_task for creation, move_task for moving list, and set_custom_field_value for single custom-field writes.
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 important behavioral aspects beyond annotations: the guest gains visibility into every task, Enterprise plan requirement (403 on other plans), and specific error codes (403, 404). Annotations already indicate mutability (readOnlyHint=false), but description adds significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headers (When to Use, When NOT to Use, Returns, Examples, Error Handling). Front-loaded with purpose. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: purpose, usage guidelines, enterprise limitation, error handling, sibling differentiation, and an example. Missing explicit mention of the include_shared parameter, but output schema exists for response details. Slight gap in not explaining that the guest must already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain all parameters in detail. It provides an example showing list_id, guest_id, and permission_level, but omits the optional include_shared parameter entirely. Schema description coverage is 0%, so description should compensate more. However, the example clarifies usage of the required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shares a List with an existing guest at a given permission level, specifying that the guest gains visibility into every task. It explicitly differentiates from siblings by naming alternatives in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to Use' and 'When NOT to Use' sections, with clear references to sibling tools (clickup_add_guest_to_task, clickup_add_guest_to_folder) and a note about Enterprise plan restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive nature; description adds context that the folder starts empty, only accepts name initially, and returns a confirmation string or error, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loaded purpose, and includes example and error handling. While slightly long, it remains useful and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral details, parameters, return value, error handling, and related tools, making it fully contextual for a simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description reinforces the schema parameters with context about the API endpoint and an example. Though schema coverage is marked as 0%, the description adds value beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Folder inside a Space' and differentiates from sibling tools like clickup_create_folder_from_template and folderless list tool, with explicit 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections, plus a tip about enabling folder-level statuses via clickup_update_folder, providing clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior when return_immediately is default, suggests re-checking with clickup_get_folder. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections, examples, and error handling. Slightly lengthy but each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use cases, async behavior, error codes, return type, and provides an example. Output schema exists but description adequately explains return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not elaborate on parameters beyond schema; schema has detailed descriptions so burden is shared, but description adds minimal param insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Folder from a template, and distinguishes it from clickup_create_folder for plain empty folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections, with direct reference to sibling tool clickup_create_folder, and prerequisite mention of clickup_get_folder_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds detail about what is created (task or subtask), the return format (confirmation string), and error conditions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections. Slightly verbose but every sentence adds value. Examples and error handling are helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: covers all major features (subtasks, custom fields, markdown, etc.), includes return format, examples, and error handling. Given the output schema exists, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having parameter descriptions, the context signals indicate 0% coverage. The description compensates with a summary of supported parameters (assignees, tags, custom fields etc.) and rich examples that demonstrate usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a task inside a List' with a specific verb and resource. Distinguishes from siblings like clickup_update_task and clickup_create_task_from_template in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear guidance. Also includes error handling advice (400/404) which helps the agent diagnose failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds that it posts to a specific endpoint, returns a confirmation string with ID/hist_id/timestamp, explains the nesting behavior, and notes error handling (404 for wrong comment_id). This fully discloses the operation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (endpoint, when to use/not, returns, example, error handling). It is somewhat lengthy but every part adds value; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with complex nesting semantics, the description covers endpoint, usage context, return format, error handling, and example—leaving no gaps. The presence of a rich output schema further supports completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not describe parameters beyond an example. However, the input schema itself has thorough descriptions for all five properties, so the agent can rely on schema. Per guidelines, with schema coverage low (0% from description), baseline is 3; no additional value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 as 'Reply inside an existing comment's thread.' It specifies the endpoint and distinguishes itself from top-level comment creation, which is directly relevant given sibling tools like clickup_create_task_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools (clickup_create_task_comment, etc.), providing clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by specifying the HTTP method (POST), endpoint, return value (confirmation string with key fields), and detailed error handling (400/404, specific error code TIMEENTRY_072 and workaround). Annotations already indicate non-readonly and open-world, but description adds rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections (when to use, examples, error handling). Front-loaded with purpose. Slightly long but each sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple params, mutual exclusivity, default values, error codes) and the presence of an output schema, the description covers the key behavioral aspects, return format, and error scenarios comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the description provides examples showing duration/stop mutual exclusivity and notes default team_id. However, many parameters (tags, assignee, custom_task_ids) are not individually described; the schema itself provides descriptions, so the description adds limited additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Log a completed (already-finished) time entry.' which is a specific verb and resource. It clearly distinguishes from sibling tool clickup_start_time_entry by stating when not to use (for running timers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (backfilling time, logging completed blocks) and when NOT to use (starting a running timer, directing to alternative clickup_start_time_entry). Examples further clarify usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only. The description adds that deletion is permanent, works uniformly on all comment types, returns a confirmation string or error, and handles 404 specifically. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every section serves a purpose: API call, usage guidelines, return type, example, error handling. No fluff, well-organized.
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?
Covered: purpose, HTTP method, when to use/not use, return format, example, error handling. Output schema exists but description still explains return values. No gaps for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only includes an example without adding meaning beyond the schema's description of comment_id. The parameter is simple, but the description does not provide additional guidance on obtaining the ID or edge cases.
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 a clear verb-resource pair: 'Permanently delete a comment.' It also specifies the HTTP endpoint and distinguishes from sibling clickup_update_comment.
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 when-to-use ('to remove a comment posted in error or no longer relevant') and when-not-to-use ('to just fix wording or mark it resolved — use clickup_update_comment instead'). Clearly contrasts with a 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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds value by noting that renaming updates the tag everywhere it's already applied, that tag_name is URL-encoded automatically, and includes error handling details. It does not contradict annotations.
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 well-organized with sections and is largely concise. However, the 'Returns' and 'Error Handling' sections could be slightly trimmed without losing 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 and the presence of a output schema, the description covers behavior (URL encoding, global update), usage scenarios, error handling, and examples. It is fully sufficient for an AI agent to 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?
The input schema already provides descriptions for all parameters, so the description adds limited semantic value. However, it clarifies the automatic URL encoding of tag_name (not in schema) and provides concrete examples that illustrate parameter usage, which aids 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 begins with 'Rename and/or recolor an existing Space tag', which is a specific verb+resource combination. It clearly distinguishes from sibling tools like clickup_create_space_tag and clickup_delete_space_tag.
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' and 'When NOT to Use' sections, including a direct reference to the sibling tool clickup_create_space_tag for creating new tags. This gives clear guidance on 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?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds valuable behavioral context: no pagination (full palette), error handling for 404, and return format details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: main description, When to Use, When NOT to Use, Returns, Examples, Error Handling. Concise and front-loaded with the main action. No unnecessary content.
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?
Description covers return format, error handling, and usage context. For a simple read-only tool with 2 parameters, it is nearly complete. Minor gap: no explicit mention of authentication or rate limits, but annotations cover safety profile.
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 descriptions for both parameters. Description adds examples and contextual guidance on when to use response_format, but doesn't significantly enhance what schema already provides. Marginal 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?
Description explicitly states 'List every task Tag defined in a Space, with its foreground/background colors.' It uses a specific verb and resource, and distinguishes from siblings like clickup_get_task for seeing tags on a specific 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?
Has dedicated 'When to Use' and 'When NOT to Use' sections, providing clear guidance. It explicitly names an alternative tool (clickup_get_task) for when to not 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds implementation details (HTTP call), naming trap warning, and error handling (400/404), which provides useful behavioral context beyond the annotations.
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 well-structured with headings and examples, but it is fairly long. It front-loads the main action and includes necessary details. It is not overly verbose, but could be slightly more concise without losing clarity.
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 (1 required param, output schema exists) and annotations covering safety, the description is thorough: it covers purpose, usage guidelines, error handling, return format, and examples. It leaves no obvious gaps for an agent to make mistakes.
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 full descriptions for all parameters (team_id, group_ids, response_format). The description adds semantic clarification: explains the team_id vs group_id distinction, provides examples, and describes the output format selector. This goes beyond the 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 'List the User Groups in a Workspace' and specifies the endpoint slug. It distinguishes the tool from sibling tools by clarifying the naming trap and resource type, making it easy for an agent to understand exactly what this tool returns.
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?
Includes explicit 'When to Use' and 'When NOT to Use' sections. It tells the agent to use this for looking up group_id before update/delete, and to use a different tool for listing plain workspace members. This provides clear guidance on tool selection.
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 plan restriction (Enterprise only, 403 on other plans), describes the scope of removal (every task/list/folder), and explains error handling (403, 404). This adds significant context beyond annotations which indicate destructive and idempotent hints.
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?
Well-structured with a clear summary, usage guidelines, examples, and error handling. Front-loaded with main action. No unnecessary 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?
Covers the essential aspects: what it does, when to use, plan restrictions, expected output, and error codes. Output schema is mentioned indirectly via return description. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (tool description does not describe parameters), so the description must compensate. However, it only provides an example usage without adding meaning beyond what the input schema already provides (workspace ID and guest ID descriptions are in schema). The example does not clarify sources or formats for the 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 action: 'Revoke a guest's access to an entire Workspace.' It uses a specific verb and resource, and distinguishes from siblings by noting it is not scoped to a single item, with explicit alternatives provided.
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 ('Offboarding an external collaborator entirely') and when NOT to use, with direct references to alternative tools (clickup_remove_guest_from_task/_list/_folder).
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes further by detailing pagination (cursor-based), error handling (401, 404), output format, and the purpose of obtaining doc IDs for subsequent operations.
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 well-structured with clear sections and examples, but it is fairly verbose. Every section serves a purpose, but slightly more conciseness could be achieved without losing clarity.
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 complexity (multiple filters, pagination, error handling), the description covers all essential aspects: purpose, usage, pagination mechanism, examples, and error scenarios. Output schema exists but the description still summarizes returns.
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 provides detailed descriptions for all parameters, so the description adds little new parameter-level semantics. However, it gives high-level filtering concepts and pagination flow, which adds some 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 'Search the Docs in a Workspace' and explains filtering capabilities. It distinguishes itself from siblings like clickup_get_doc and clickup_create_doc by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear guidance on appropriate scenarios and directing to alternative tools (clickup_get_doc_pages, clickup_create_doc).
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 only explicitly set fields are sent, leaving others unchanged (idempotent behavior). Mentions support for 'markdown_content' and 'unset_status', and describes the return format (confirmation string or error). Annotations already indicate readOnlyHint=false and destructiveHint=false, which the description reinforces and adds detail. However, does not explicitly state that the schema is non-exhaustive (openWorldHint=true), though that is a minor gap.
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?
Well-structured with clear sections: main purpose, usage guidelines, return type, three concrete examples, and error handling. Every sentence provides value without redundancy. Front-loaded with the most important 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 the main modifiable fields, provides examples, and handles errors. Given the tool complexity (many optional fields) and the presence of an output schema (not shown), the description is sufficient but could optionally mention that only the listed fields are modifiable and that others (e.g., metadata) are not controlled here.
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 contains descriptions for each field, so the description's value is in contextual grouping (e.g., 'markdown_content' as an alternative to 'content', 'unset_status' to clear color) and practical hints like using Unix epoch for due_date. This adds useful 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 opens with 'Update a List's name, description, dates, priority, assignee, or color,' clearly specifying the verb (Update) and resource (List) with the set of modifiable attributes. This distinguishes it from sibling tools like create_list (creation), get_list (read-only), and delete_list (deletion).
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?
Includes dedicated 'When to Use' and 'When NOT to Use' sections. Explicitly states use cases (renaming, changing description, etc.) and excludes unrelated operations like changing a Task's status. Also clarifies that the 'status' field is just a color, preventing confusion with task statuses.
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?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. Description adds that reactions are lower-cased automatically and provides error codes, adding context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, an example, and error handling. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, annotations, and presence of an output schema, the description covers purpose, usage, parameters, and errors adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for each parameter. The description adds useful context like lower-casing behavior and default workspace, but schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add an emoji reaction to a Chat message.' It uses a specific verb-resource pair and distinguishes from sibling tools like clickup_delete_chat_reaction and clickup_get_chat_message_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections with specific alternative tool names. Error handling details further guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, but the description adds valuable context: returns a confirmation string or error string, explains error handling for 403 and 404, and notes that it is a mutation but not destructive. This goes beyond the bare annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, prerequisites, when to use/not use, returns, examples, error handling). It is concise yet comprehensive, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (permission levels, guest prerequisite, plan restriction, error handling), the description covers all essential aspects: purpose, prerequisites, usage conditions, return value, error handling, and examples. It references sibling tools and includes sufficient detail for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds value through examples showing usage of custom_task_ids and team_id, and clarifies permission_level enum values ('read (view), comment, edit, or create (full access)'). This compensates for the lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Share a single task with an existing guest at a given permission level.' It specifies the action (share), resource (task), and recipient (existing guest), and distinguishes itself from sibling tools like clickup_add_guest_to_list and clickup_add_guest_to_folder by emphasizing a single task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, directs to alternative tools for list/folder sharing, and states prerequisites (guest must exist via clickup_invite_guest_to_workspace) and plan restrictions (Enterprise only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show it's a write operation (readOnlyHint: false), idempotent (idempotentHint: true), and non-destructive (destructiveHint: false). The description adds context about returning a confirmation string, error handling (404 if tag/task missing), and that the tag must exist. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use/not, returns, examples, error handling). Every sentence is informative, no redundancy, and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema, good annotations), the description covers purpose, prerequisites, usage guidance, examples, and error handling comprehensively. It is self-contained and sufficient for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes parameters with clear descriptions. The description adds value through practical examples that demonstrate usage of all parameters, including optional ones like team_id and custom_task_ids, and explains fallback behavior for team_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply an existing Space tag to a task,' using a specific verb and resource. It distinguishes from sibling tools like clickup_create_space_tag (for creating tags) and clickup_remove_tag_from_task (for removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, directing users to clickup_create_space_tag for creating new tags. It also states the prerequisite that the tag must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds critical behavioral context: requires specific ClickApp, does not move the task, returns confirmation or error string, and details error handling for 403 and 404.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, prerequisites, when to use/not use, returns, examples, error handling). Every sentence is informative and earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (requires a ClickApp, has a specific behavior distinct from move), the description covers all necessary aspects: prerequisite, use cases, alternatives, return format, and error handling. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for list_id and task_id. The description adds an example and mentions that the task stays in its original list, but does not elaborate further on parameter semantics. Since schema covers the parameters, the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds an existing task to an additional list, distinguishes from moving a task, and notes it does not duplicate but adds membership. It is specific and differentiates from sibling tools like clickup_add_guest_to_list or clickup_add_tag_to_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections with an alternative (move-task tool) and prerequisite (Tasks in Multiple Lists ClickApp). Provides clear guidance on when to invoke this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states the checklist is empty initially, explains error codes (404, 403) and their meanings, and specifies the return format (confirmation string with name and id). This is valuable context not covered by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly structured with sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) that are concise and valuable. Every sentence adds information, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (task ID variants, team ID fallback, error handling, relation to other tools), the description covers all essential aspects: purpose, usage boundaries, return type, examples, and error conditions. It is fully adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema descriptions cover parameter basics, the description enriches semantics with usage examples showing different parameter combinations (e.g., custom_task_ids fallback to CLICKUP_TEAM_ID). It also clarifies the team_id requirement when custom_task_ids is True, which is not explicit in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 an empty checklist to a task, with a specific verb ('Add') and resource ('checklist'). It distinguishes from the sibling tool clickup_create_checklist_item by noting that items are added afterwards, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use (breaking a task into trackable sub-steps) and when NOT to use (for work requiring assignee/due date/status, with the alternative clickup_create_task with parent). This provides clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with the write operation. The description adds context: it posts multipart/form-data, returns id and URL (never bytes), and notes that some plans may 404. It does not explicitly mention file size limits or cleanup behavior, but overall adds good transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for purpose, mechanism, usage guidance, return value, examples, and error handling. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (binary entity_type, dependency on another tool, error cases), the description covers all necessary aspects: the upload process, required follow-up for custom fields, return values, and error scenarios. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter, but the description adds crucial context: the distinction between entity_type 'attachments' vs 'custom_fields', that file_path must be local, and the post-upload step for custom fields using `clickup_set_custom_field_value`. Examples further clarify usage, compensating for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 to a task or File-type Custom Field (v3). It distinguishes itself from siblings like `clickup_create_task_attachment` (modern replacement) and `clickup_get_entity_attachments` (for reading), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections name alternatives and provide fallback guidance. Error handling explains when to use `clickup_create_task_attachment` if the endpoint returns 404, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutable but non-destructive operation. The description adds context by explaining type-specific behaviors (e.g., 'automatic' requires task_ids/list_ids) and error codes (404, 400). It does not cover authorization or side effects, but the main behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: header, type explanation, usage guidance, return info, example, and error handling. Every sentence adds value, and the format is front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multiple key result types and parameter dependencies, the description covers essential aspects: type semantics, when to use automatic, error conditions, and return value shape. The presence of an output schema (acknowledged but not shown) does not detract from the completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already has comprehensive descriptions (despite the 0% coverage signal), the description adds value by explaining the role of 'type' in progress tracking and the dependency of 'automatic' on task_ids/list_ids. The example further clarifies parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a Key Result (Target) to a Goal,' using a specific verb and resource. It differentiates from sibling tools by explicitly noting that updating is handled by 'clickup_edit_key_result.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use ('Breaking a Goal down into one or more measurable targets') and when-not-to-use ('Updating an existing Key Result's progress') with an alternative tool. Error handling details further guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the tool's behavior: it creates a comment (write operation) and returns a confirmation string or error. It details possible error responses for 404 and 403. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions. The description adds valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized with clear sections: single action line, HTTP endpoint, usage conditions, return format, example, and error handling. Every sentence serves a purpose, no redundancy. It is front-loaded and efficiently scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains the return format (confirmation with id, hist_id, timestamp) and error strings. Usage context (list vs. task comment) is clarified, and error codes are provided. All necessary information for invocation is covered without relying on external references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all parameters with detailed descriptions. The free-text description provides an example but does not elaborate on parameter semantics beyond what the schema offers. Schema description coverage is 0% (description doesn't explicitly list parameters), but the schema compensates. The example adds marginal value, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Add a comment to a List's info panel,' which clearly states the verb and resource. It immediately distinguishes from commenting on a task by specifying 'not on an individual task' and referencing the sibling tool clickup_create_task_comment. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections are provided. 'When to Use' gives a concrete example (status update visible to all). 'When NOT to Use' identifies the alternative precisely. Error handling hints further guide correct usage. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false) and non-destructive nature. Description adds useful behavioral context: name derivation, error handling (400, 404), and return confirmation structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient structure with separate sections for purpose, usage guidance, returns, examples, and error handling. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers primary behavior, differentiation from siblings, parameter constraints, return value, and error scenarios. With an output schema present, the description provides sufficient context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has detailed descriptions for all parameters. Description adds value by explaining the combined location object format and the absence of a name field. Examples illustrate usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly 'Create a Chat channel bound to a Space, Folder, or List.' Distinguishes from sibling tools like clickup_create_chat_channel (standalone) and clickup_create_direct_message (DM) through explicit when-not-to-use sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use (give a location its own conversation) and when not to (standalone channel, DM) with alternative tool names. Provides examples for clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) but non-destructive (destructiveHint=false). The description adds that it returns a confirmation with name and id, and explains error handling for 404. This goes beyond annotations, though it could mention any required permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized with clear sections: main action, when to use, when not to use, returns, examples, and error handling. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (context signals), the description appropriately covers return behavior and error scenarios. Examples cover both top-level and nested page creation. All essential decision points are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all 7 parameters (name, doc_id, content, etc.), so the description doesn't need to repeat them. The description adds useful examples showing typical usage patterns, which helps the agent understand how to combine parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add a page to an existing Doc' and specifies optional nesting. It distinguishes from siblings like clickup_create_doc and clickup_edit_page in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('To append a new section/page to a Doc you already created or found') and when not to use, with references to alternative tools for creation and modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the return type (confirmation string) and error handling (404 for nonexistent space, 400 for duplicate tag). Annotations do not contradict, and the description provides useful behavioral context even though openWorldHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: summary, usage guidelines, return info, examples, and error handling. It is concise with no wasted words, front-loading the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, when to use it, what it returns, and common errors. It is complete for a tag creation tool with good sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover parameters well, and the description reinforces with examples showing optional color usage. This adds meaning beyond the schema, particularly for the optional tag_fg and tag_bg parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Add a new task Tag (with optional colors) to a Space's tag palette.' It uses specific verbs and resources, and distinguishes itself from sibling tools like clickup_add_tag_to_task and clickup_edit_space_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear context. It advises using this tool before applying tags to tasks and directs the user to clickup_edit_space_tag for renaming or recoloring, offering clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent. Description adds that it performs a POST request and returns a confirmation string with new task name and ID. Also mentions error handling (404). No contradictions. Small gap: no explicit mention of side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with clear sections: overview, endpoint, usage guidelines, returns, example, error handling. No redundant sentences; every line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema describes parameters and an output schema likely returns the result, the description provides all necessary additional context: purpose, HTTP method, how to get template IDs, when to use, example, and error handling. Covers all key aspects for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes each parameter (name, list_id, template_id). Description adds context by showing the endpoint pattern and explaining how to obtain template IDs via `clickup_get_task_templates`. Provides a concrete example. Schema coverage is 0% but parameters are described in the schema, so description adds complementary value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a task in a List from a saved task template.' Specifies verb, resource, and distinguishes from sibling `clickup_create_task` (plain task). Mentions the HTTP POST endpoint for technical clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, with direct reference to alternative tool `clickup_create_task` for plain tasks. Offers actionable guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive, but description adds specifics: it subscribes an endpoint, responds with webhook id and health object, and details error handling (400, 404). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use/not use, returns, examples, error handling). No redundant information, every sentence is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and existence of an output schema, the description covers all necessary aspects: creation, filtering, wildcard events, return fields, and error codes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter, but the description adds value by showing usage examples and specifying error handling for invalid endpoint or unknown event names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it registers a webhook to push events to an endpoint. It uses a specific verb ('Register a webhook') and resource ('ClickUp events'), and distinguishes from siblings like clickup_get_webhooks and clickup_update_webhook by indicating when not to use those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (to wire into external systems, watch single list/task) and when not to use (to inspect/repair existing webhooks, for one-off reads). It also provides concrete examples of parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds value by explaining error handling (404 means edge or task ID missing) and that direction must match creation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for usage, returns, examples, and error handling. Every sentence adds value, no fluff. Front-loaded with 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?
Covers all necessary aspects: usage scenarios, parameter selection rules, expected return, and error handling. The tool has moderate complexity, and the description fully equips the agent to use it 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 descriptions for parameters are present. The description goes beyond by explaining the mutual exclusivity of depends_on and dependency_of in context (same direction as creation) and provides an example, adding practical 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?
Title and description clearly state the tool removes a blocking dependency edge between tasks. It is distinct from sibling tool clickup_delete_task_link which removes non-blocking associations, and from clickup_add_dependency which adds dependencies.
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' sections provide clear guidance: use to unblock a task, do not use for non-blocking associations (directs to clickup_delete_task_link). This helps the agent choose correctly.
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?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that it permanently deletes the goal and all key results, returns a confirmation string, and handles 404 errors for non-existent/already deleted goals.
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?
Well-structured with clear sections (purpose, when to use/not use, returns, errors). No redundant sentences; every part contributes useful 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 (one parameter, no output schema needed), the description covers behavior, error handling, and alternatives comprehensively. Meets all needs for correct invocation.
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 (goal_id). The input schema already provides a description. The tool description does not add further details about the parameter beyond implying its role, so 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 'Permanently delete a Goal and all of its Key Results', specifying the verb, resource, and scope. It distinguishes itself from the sibling tool `clickup_delete_key_result` which only deletes a single 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, including an alternative tool (`clickup_delete_key_result`), giving clear guidance on when to invoke this tool versus alternatives.
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?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds context: the delete is permanent, does not delete member accounts or affect their access outside the group, and the API endpoint slug is misleading. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main purpose, when to use, when not to use, returns, example, error handling. Each sentence adds value, and the length is appropriate for the complexity.
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 presence of an output schema, the description adequately covers purpose, usage, behavior, parameter details, example, and errors. It provides sufficient context for an agent to correctly select and invoke this 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?
The input schema already provides a clear description for group_id: 'User Group id to permanently delete. This is NOT a Workspace/team_id.' The description repeats this caution and adds context about the endpoint but does not add significant new parameter semantics. Baseline of 3 maintained as schema description coverage is high.
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 User Group from a Workspace.' It explains the API endpoint slug discrepancy and distinguishes from deleting the workspace or members. The verb 'delete' and resource 'User Group' are specific, and it notably differentiates from sibling tools like clickup_delete_space or clickup_delete_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?
Explicit 'When to Use' and 'When NOT to Use' sections are provided. The NOT to Use case specifies an alternative: 'clickup_update_user_group' for removing individual members. It also includes error handling notes for 404 and 403 responses.
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 discloses behavioral traits beyond annotations: it explains nesting behavior via parent/clear_parent, mentions the return type (confirmation string), and provides error handling (404). Although annotations already indicate non-destructive and idempotent, the description adds practical context without contradiction.
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 well-structured with sections and examples, yet remains concise. The first sentence immediately conveys the tool's purpose, and each subsequent part earns its place 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's complexity (multiple edit actions, nesting) and the availability of an output schema, the description covers return values, error handling, and provides examples. It leaves no significant gaps for an AI agent to understand when and how to invoke the 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 description coverage is 0% (context signal), so the description must compensate. It explains key parameters like parent, clear_parent, resolved, and assignee with examples. However, it does not detail all parameters (e.g., checklist_id, name) beyond what the schema provides, but the usage context adds 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 begins with a clear enumeration of actions: 'Rename, (un)resolve, reassign, or nest/un-nest a checklist item.' It specifies the resource (checklist item) and the operations, which distinguishes it from sibling tools like clickup_delete_checklist_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?
Explicit 'When to Use' and 'When NOT to Use' sections are provided. The 'When NOT to Use' section names the alternative tool clickup_delete_checklist_item, offering clear guidance on tool selection.
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?
Adds patch semantics ('Only fields you pass are sent'), plan restriction ('Enterprise plan only'), and error handling (403, 404). Annotations already provide idempotentHint and destructiveHint, but description adds significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, no redundant sentences. Efficient and 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?
Covers all necessary aspects: purpose, partial update behavior, plan limitation, usage guidance, return format, and error handling. Output schema exists, so return details are 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 description coverage is 0% per context, so description should explain parameters. It lists some fields in 'When to Use' and provides an example, but does not enumerate all available parameters (e.g., can_edit_tags, custom_role_id). Adequate but not thorough.
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 'Update an existing guest's permission flags or custom role on a Workspace' with specific verb and resource. Distinguishes from sibling tools like add_guest_to_*.
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' sections, naming alternatives (per-task/list/folder tools). Provides clear context for 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: cursor-based pagination, return of next_cursor, and error handling for 404. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). Every sentence adds value, no fluff, and it is 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?
Given no output schema, the description covers return values (reaction emoji name, user, next_cursor), pagination, examples, and error handling. It references another tool for pagination details, which is sufficient for a read-only list 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?
The input schema already describes each parameter well (e.g., limit range, cursor usage). The description adds minimal extra: it mentions cursor pagination and gives an example, but does not significantly augment the schema's parameter descriptions. 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 emoji reactions on a chat message, with a specific verb 'List' and resource. It distinguishes from sibling tools like clickup_add_chat_reaction and clickup_delete_chat_reaction by explicitly stating when not to use.
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 includes explicit 'When to Use' and 'When NOT to Use' sections, referencing sibling tools for adding/removing reactions. This provides clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return format (name, id, next_cursor), error handling (404 for unknown message_id), and pagination behavior. No contradictions with annotations 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 well-structured with clear headings, concise sentences, and no extraneous information. It efficiently communicates purpose, usage, return values, pagination, and error handling in a compact format.
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 presence of an output schema and comprehensive annotations, the description covers all necessary aspects: return values, pagination, error handling, and usage context. It is fully adequate for an AI agent to understand and invoke the 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?
The description does not elaborate on individual parameters beyond an example, but the input schema already contains complete descriptions for all parameters. According to the rubric, high schema coverage (though signal says 0%, schema actually has descriptions) yields a 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 'List' and the resource 'users @-tagged in a Chat message', along with the pagination method. It effectively distinguishes itself from the sibling tool clickup_get_chat_channel_members, which lists channel members instead of 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear guidance on appropriate usage and explicitly naming an alternative tool for listing channel members.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the tool's safety profile is clear. Description adds value by specifying the default return format (Markdown) and error handling (404 for missing/deleted goal), which are behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Descriptions is well-structured with clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling). Every sentence adds value, and the most important information is 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 the presence of an output schema (not shown), the description does not need to detail return fields. It mentions the Goal's fields and Key Results, which is sufficient. Error handling is covered, and annotations provide safety context. The tool is simple with only two parameters, so the description is 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?
Input schema provides descriptions for both parameters (goal_id as UUID, response_format as enum), but schema description coverage is 0%. Description adds an example with goal_id and mentions the return format, giving practical context not in the schema. However, it does not explicitly describe the response_format 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?
Description clearly states it gets a single Goal's full detail including Key Results, with a specific verb and resource. It distinguishes itself from the sibling tool `clickup_get_goals` which is for listing.
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 includes 'When to Use' and 'When NOT to Use' sections, providing clear guidance to use this tool for inspecting one goal's progress before editing, and to use `clickup_get_goals` for listing many goals.
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?
Annotations already declare readOnly, idempotent, non-destructive. Description adds return details (description, dates, color, priority, assignee, parent Folder/Space) and error handling (404 for missing/not accessible). 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?
Concise sections with clear headings (When to Use, When Not to Use, Returns, Examples, Error Handling). Front-loaded main 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?
Fully covers what the tool does, when to use, what it returns, example usage, and error cases. No gaps given the tool's simplicity and presence of output schema and annotations.
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 descriptions for both parameters. The description provides example usage with list_id and response_format, adding practical context beyond schema. Error handling also informs about invalid list_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 'Fetch full detail for a single List by id', using specific verb and resource. It distinguishes from sibling tools like clickup_get_lists by specifying when to use this tool vs enumerating many lists.
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' and 'When NOT to Use' sections, naming alternative tools (clickup_get_lists, clickup_get_folderless_lists) for different scenarios.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint; the description adds meaningful context about return structure (separate arrays for custom and built-in views), error handling, and output format, without contradiction.
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?
Well-structured with clear sections (main description, when to use, when not, returns, examples, error handling). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, usage context, return behavior, and error scenarios. The presence of an output schema further reduces the need to explain return values.
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?
Despite 0% schema description coverage per context, the description provides an example with 'list_id' and implies the 'response_format' parameter by mentioning return formats. However, it does not explicitly describe the parameters beyond that, leaving some burden unaddressed.
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 task and page views for a List, with a specific verb and resource. It distinguishes from sibling tools like 'clickup_get_team_views' by specifying it's for List-level views.
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 (discovering List-level views before related operations) and when NOT to use (other levels refer to specific sibling tools), with direct mentions of alternatives.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description focuses on additional behavioral traits: the endpoint, distinction from group membership, explanation that this surfaces items not normally visible via normal hierarchy, and error handling (404/401). No contradictions were found.
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 well-structured with clearly labeled sections: main statement, endpoint, explanation, When to Use, When NOT to Use, Returns, Example, Error Handling. Every sentence adds unique value without redundancy. It is concise yet comprehensive.
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-only list tool with one required parameter, the description covers purpose, usage guidelines, output format, error handling, and provides an example and alternatives. An output schema exists (not shown), so return value documentation is covered elsewhere. The description is fully complete for this 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?
The input schema already provides good descriptions for both parameters (team_id: 'Workspace id to look up items shared...', response_format: 'Output format: markdown or json'). The description adds little semantic value beyond the schema; it mentions team_id in the endpoint URL and example, and notes the output format, but does not provide new details. Given schema coverage is adequate, 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 purpose: 'List the Tasks, Lists, and Folders individually shared with the caller.' It specifies the verb (list), resources (tasks, lists, folders), and scope (individually shared), distinguishing it from shared group membership. The endpoint is also mentioned, providing full 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 includes explicit 'When to Use' and 'When NOT to Use' sections. It advises using the tool to audit individual shares and explicitly warns against using it for the inverse direction (who has access to a specific item). It names alternative tools (clickup_get_list_members, clickup_get_task_members) for that purpose.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns only top-level workspace fields, mentions response format options, and provides error handling details for 404, 401, and 403. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for purpose, when to use, when not to use, returns, examples, and error handling. It is concise and front-loaded, with no extraneous 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 output schema exists, the description does not need to detail return values. It covers scope, usage, alternatives, and error handling. Complete for a read-only list tool with good annotations.
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 0% per context (though schema itself has descriptions). The description does not elaborate on parameter details beyond the schema, but the schema is rich. The example helps, but parameter semantics are largely covered by 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 'List the Workspace-scoped Custom Fields' with the specific API call and scope. It distinguishes from sibling tools by noting it only returns workspace-level fields, not inherited ones.
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 ('inventory organization-wide Custom Fields') and when not to use ('to find a field usable on a specific task'), with a clear alternative: 'clickup_get_list_custom_fields'.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the API endpoint, return format (markdown/JSON list with name, color, creator), and error handling (404 for invalid team_id). Minor missing: no mention of pagination, but unlikely needed for a list of tags.
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 well-structured with clear sections: main description, when to use, when not to use, returns, example, error handling. It is concise with no extraneous 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 the tool's simplicity (1 required parameter, read-only, output schema exists), the description covers purpose, usage, an example, and error handling adequately. No gaps identified.
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 describes team_id and response_format. The description adds value by providing an example usage (params = {'team_id': '123'}) and mentioning the API call path.
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 every tag ever applied to a time entry in the workspace, and distinguishes itself from siblings by noting that tags on a specific entry are available via clickup_get_time_entry or clickup_get_time_entries.
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' sections provide clear guidance on discovering tags before tagging or renaming, and direct users to alternative tools for per-entry tags.
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?
Annotations indicate read-only, idempotent, non-destructive. Description adds that it returns only webhooks created by the authenticating user, includes health.status and fail_count, and lists error handling (404, 401). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (main purpose, when to use, when not, returns, examples, error handling). Each sentence adds 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?
Given the tool's simplicity (2 parameters with schema descriptions) and presence of an output schema (though not shown), the description covers all necessary context: purpose, usage, return content, error handling, and examples. 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?
The input schema already provides good descriptions for both parameters (team_id, response_format). The tool description does not add additional parameter meaning beyond what the schema states, 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 starts with 'List the webhooks registered in a Workspace, with their delivery health,' clearly stating the verb (list) and resource (webhooks). It differentiates from siblings like clickup_create_webhook and clickup_delete_webhook by specifying it lists existing webhooks and includes health status.
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' sections: use for finding webhook IDs before update/delete, audit health; not for creation (use clickup_create_webhook). Provides clear contextual 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?
Annotations already mark readOnlyHint, idempotentHint, destructiveHint, so safety is clear. Description adds valuable detail: returns 'Infinity' for guest totals on unlimited plans, error handling for 404/401. 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?
Well-structured with headings (When to Use, When NOT to Use, Returns, Examples, Error Handling). No fluff, every section adds value. Concise yet comprehensive.
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 aspects: purpose, usage context, parameter behavior, return structure, error scenarios, examples. Agent has everything needed to invoke correctly, even without output schema (though one exists).
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 0% per context, but description compensates by noting default team_id from CLICKUP_TEAM_ID and showing response_format usage in examples. Does not fully describe each parameter's meaning but enough for 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?
Clearly states it reports workspace seats (used/total/available for members and guests). Distinguished from sibling clickup_get_workspace_plan by focusing on seat counts rather than plan tier.
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' (before inviting members/guests) and 'When NOT to Use' (to read plan tier, with alternative clickup_get_workspace_plan). Full guidance on context.
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 discloses guest limitations (only sees shared items), plan restriction (Enterprise only), and references related functions. Annotations (readOnlyHint=false) are consistent, and description adds value beyond annotations with error handling details.
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?
Well-structured with clear sections (description, when to use, returns, examples, error handling). Concise yet comprehensive, with no 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?
For a tool with one required parameter and an output schema, the description covers purpose, usage, alternatives, error codes, and includes an example. It is fully adequate for an agent to understand and invoke the tool 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?
Schema description coverage is 0% (context signal), but the description provides an example with one parameter (can_create_views). It does not explain optional parameters or their defaults beyond what's in the schema. The example helps but is insufficient for full 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 ('Invite an external guest to a Workspace by email') and distinguishes guests from full members. It also references sibling tools for sharing items, differentiating itself effectively.
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' sections with specific alternative tool (clickup_invite_user_to_workspace). Also notes Enterprise plan restriction, providing clear usage 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 adds valuable behavioral context beyond annotations: that members see items based on workspace sharing settings, that the tool is Enterprise-only with 403 error, and includes error handling for common failure modes. No contradiction with annotations found.
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 well-organized with clear sections, no fluff, and includes practical examples and error handling. Every sentence serves a purpose, and it is 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 relatively simple invite tool, the description covers all necessary aspects: core functionality, when to use vs. alternatives, return value, error scenarios, and an example. Nothing essential 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?
The input schema already provides descriptions for all parameters, so the description adds marginal value beyond an example usage. While schema coverage is technically 0% per context signals, the schema itself is well-described, warranting a 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 it invites a full member to a workspace by email, distinguishes between members and guests, and contrasts with the sibling tool clickup_invite_guest_to_workspace, making the purpose unmistakable.
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' sections provide clear guidance on when to choose this tool over the guest invite alternative, and also mention the Enterprise plan requirement, leaving no ambiguity.
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?
While annotations indicate `idempotentHint: true` and `destructiveHint: false`, the description adds context about the API endpoint, fallback behavior for `workspace_id`, status mapping requirements, and error handling (400/404). It doesn't explicitly confirm idempotency but covers key 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 efficiently structured: one-line purpose, endpoint detail, usage guidelines, return type, example, and error handling. No redundant sentences; all information is front-loaded and earned.
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 complexity (status mappings, custom field migration, multiple parameters), the description covers purpose, when to use/not use, parameter semantics, error codes, and provides an example. With an output schema present, return value explanation is unnecessary. Complete for agent 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?
Despite schema description coverage being 0% (likely a metric error), the description adds value by explaining `status_mappings`, `move_custom_fields`, and `custom_fields_to_move` with examples. It also notes the `workspace_id` fallback. This compensates for the lack of 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 'Move a task to a new home List' with a specific verb and resource. It distinguishes from sibling tools like `clickup_update_task` and the tasks-in-multiple-lists ClickApp, ensuring 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly provides 'When to Use' and 'When NOT to Use' sections, citing specific alternatives (`clickup_update_task` and Lists tools for multiple lists). This gives clear guidance for agent decision-making.
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?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds value by disclosing the return value (confirmation string), error conditions (404), and the nuance that the tag is not deleted from the Space. It does not discuss rate limits or authorization, but these are beyond the scope for a simple removal 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 concise, using bullet points and sections. It front-loads the core action and provides only necessary details: usage, returns, example, and error handling. No redundant sentences.
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 and the presence of complete annotations and a rich input schema, the description covers all essential aspects: purpose, usage guidelines, behavioral traits, return value, and error handling. It is fully sufficient for an agent to use this tool 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?
The input schema includes descriptions for all parameters (task_id, team_id, tag_name, custom_task_ids), covering their semantics well. The description provides an example that illustrates typical usage. While the description doesn't add much beyond the schema, the example parameter values enhance 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 verb 'Remove', the resource 'tag from a task', and the scope 'without deleting the tag from the Space'. It distinguishes from the sibling tool clickup_delete_space_tag by explicitly stating the alternative purpose.
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 'When to Use' and 'When NOT to Use' sections, including a named alternative (clickup_delete_space_tag) for deleting the tag everywhere.
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?
Annotations already present (readOnlyHint=false, etc.), but description adds meaningful context: return format (confirmation with id and channel), error codes (400, 404), and details on post_data usage. No contradiction.
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?
Concise and well-structured: main purpose, defaults, when-to-use/not, returns, examples, error handling. Every sentence adds 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 usage, parameters, return values, errors, and references sibling tool for subtypes. Lacks mention of rate limits or authentication, but annotations (openWorldHint=true) and output schema compensate. Very complete for a chat message 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?
Despite 0% schema description coverage, the description thoroughly explains parameters: default message_type, post_data usage with reference to clickup_get_chat_subtypes, assignee, followers, content_format, etc. It adds significant 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?
Clearly states 'Post a new message to a Chat channel' and distinguishes plain messages from rich posts (Announcement/Discussion/Idea/Update). Explicitly differentiates from sibling tools clickup_send_chat_reply and clickup_update_chat_message.
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?
Has explicit 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools for replying in a thread and updating messages. Includes examples and error handling.
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?
Annotations indicate idempotentHint=true and readOnlyHint=false, but the description adds value by explaining the return value (confirmation string with updated duration) and error handling (400 when no timer running). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (action, endpoint, use cases, not-to-use, returns, example, error handling). It is concise with no redundant sentences.
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 parameter) and the presence of an output schema, the description covers behavior, error handling, and usage context completely. It addresses both successful and error scenarios.
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 already describes the team_id parameter. The description adds a usage example (`params = {"team_id": "123"}`) which clarifies the parameter format and defaults. Schema coverage is 0% in description text, but the example compensates.
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 'Stop the authenticated user's currently running timer.' This is a specific verb+resource action, and it effectively distinguishes from sibling tools like clickup_start_time_entry and clickup_delete_time_entry.
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 includes explicit 'When to Use' and 'When NOT to Use' sections, referencing the related tool clickup_start_time_entry and clickup_delete_time_entry. This provides clear guidance on when to invoke this tool versus alternatives.
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?
Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds that it returns a confirmation, handles 404 errors, and that 'resolved' is a top-level body field, complementing annotations without contradiction.
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 well-structured with clear sections, bullet points for use cases, examples, and error handling. Every sentence is informative 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?
Given the input schema covers parameters, output schema exists (confirmation), and annotations present, the description is comprehensive: it covers purpose, usage guidelines, examples, and error handling. 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?
Input schema properties already have descriptions (e.g., 'New message body (omit to leave unchanged)'). The description adds little beyond summarizing that only changed fields need to be sent and noting the special handling of 'resolved', but this is 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 edits a Chat message, specifying editable fields (content, assignee, resolved state). It contrasts with sibling tools like delete and react, 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?
Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance, naming specific sibling tools (clickup_delete_chat_message, clickup_add_chat_reaction) for alternatives.
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 discloses that the endpoint only flips a flag, that status definitions cannot be set via API, and gives a recommendation to inspect results with another tool. This adds significant context beyond the 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?
The description is well-structured with sections for use cases, examples, and error handling. Every sentence is informative, and the content is front-loaded with the 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 the complexity of the status-override feature, the description adequately explains the behavior, limitations, and error codes. The presence of an output schema means return values are not the description's responsibility, but it still mentions the return format.
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 each parameter (100% coverage as seen in the schema). The tool description adds marginal extra context about the status override behavior, but the schema already covers the basic semantics, so baseline 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 renames a Folder and/or toggles its status-override setting. It names the specific HTTP endpoint and distinguishes from sibling tools by noting that List-level status changes require different 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?
Explicit 'When to Use' and 'When NOT to Use' sections are present, with a concrete example and clear guidance to avoid misuse for List-level statuses.
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?
Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. Description adds incremental owner behavior, return value (confirmation string), and error handling (404, 400). Could mention auth needs or side effects, 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?
Well-structured: purpose, incremental note, usage guidance, returns, example, error handling. Every section is concise and useful.
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 necessary aspects for a medium-complexity update tool: when to use, alternatives, parameter behavior, return value, error codes. Output schema exists to further detail return values.
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 already provides descriptions for each parameter. Description adds value by explaining that owners are changed incrementally via add_owners/rem_owners, which is not fully captured in 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?
Clearly states it updates an existing Goal's fields (name, due date, description, owners, color). Differentiates from clickup_edit_key_result in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sections with a direct sibling alternative (clickup_edit_key_result). Also notes incremental owner semantics.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds business plan requirement, error handling (400, 404), and that it is an update operation, which aligns with annotations and provides additional useful detail.
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?
Well-structured with one-line summary, endpoint, usage guidelines, returns, example, and error handling. Every sentence adds value and it is 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?
Covers all essential aspects: purpose, differentiation from sibling, prerequisites (business plan), error cases, example usage, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides good parameter descriptions (e.g., estimates notes difference from replace tool). The description adds an example call and explains the return value, complementing the schema well.
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 sets or adjusts specific assignees' time estimates on a task, leaving others unchanged. It also differentiates from the sibling tool clickup_replace_time_estimates_by_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?
Explicitly provides when to use ('Tweaking one or two assignees' estimates') and when not to use with an alternative tool mentioned, giving 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?
The description explains the replacement semantics (no partial update) and error codes (404, 400). Annotations already indicate idempotent and non-destructive, but the description adds important context about the full-replacement 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?
Well-structured with clear sections: introductory sentence, behavior note, usage guidelines, return value, example, and error handling. No wasted words, front-loaded with 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?
Covers key behavioral aspects (full replacement), prerequisites (call get_view), pitfalls (no hierarchy change), return type, and error handling. Output schema exists so return details are handled. Complete for agent 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?
While the input schema has detailed descriptions, the description adds value by explaining the need to resupply parent_id/parent_type and config blocks from get_view. It clarifies the full-replacement requirement beyond the schema's field 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 renames a view and replaces its grouping/sorting/filters/columns/settings. It distinguishes from siblings like clickup_create_view and clickup_delete_view by specifying the update action and noting the API's full-replacement 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?
Explicit 'When to Use' and 'When NOT to Use' sections. It advises using clickup_get_view first and warns against trying to move a view across hierarchy levels, directing to delete/recreate instead.
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 adds significant behavioral context beyond the annotations, including pagination details (page-based, 100 per page), return format (markdown summary or JSON), first 50 tasks rendered, error handling for missing team_id and 404, and fallback to CLICKUP_TEAM_ID. Annotations already declare readOnlyHint, idempotentHint, and non-destructive, which are consistent.
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 well-structured with clear sections and front-loaded with the main purpose. While it is relatively long (several paragraphs), each sentence earns its place by contributing essential information about usage, filters, pagination, or error handling.
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 complexity (rich filters spanning workspace), the description covers all key aspects: purpose, when to use/avoid, filter parameters via examples, pagination, error handling, and return format. The presence of an output schema is noted but the description still explains the return format sufficiently.
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 detailed descriptions for most parameters, so the description's additional value is in grouping filters (e.g., space_ids, project_ids, list_ids) and providing usage examples that demonstrate combinations like date ranges with ordering. The examples further clarify 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?
The description clearly states the tool searches tasks across the entire workspace with rich filters, and explicitly contrasts with sibling tools like clickup_get_tasks (limited to one list) and clickup_get_task (single task by ID). The verb 'search' and resource 'workspace tasks' are 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?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear context for when to choose this tool over alternatives. It advises against using it when a single list is known (recommending clickup_get_tasks) or when a task ID is available (recommending clickup_get_task), and notes that clickup_get_tasks is cheaper.
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?
Annotations already indicate read-only, idempotent, non-destructive. Description adds critical context: Enterprise-only, workspace owner token required, pagination behavior, error codes (403, 400). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (When to Use, Pagination, Examples, Error Handling) and front-loaded with purpose. It is somewhat lengthy but each section adds necessary detail. Could be slightly more 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?
Given the complexity of audit log queries, the description covers all essential aspects: usage context, limitations, pagination mechanics, error handling, and examples. With annotations and output schema, it is sufficiently complete for an AI 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?
While the schema provides detailed descriptions for all parameters, the description adds value by explaining pagination (page_timestamp, page_direction), giving examples, and noting the required applicability. This supplements the 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?
The description clearly states it queries a workspace's audit trail, specific to Enterprise and workspace owner. It differentiates from sibling tools by focusing on audit logs for security/compliance, not task activity.
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 (security/compliance review) and when not to use (task activity feeds), along with plan and ownership restrictions. This helps the agent decide appropriately.
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 key behaviors beyond annotations: note about custom status workflows being silently ignored (verified live), and that only set fields are sent (omitted fields unchanged). Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, and description adds valuable context without contradiction.
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 well-structured with sections (main purpose, When to Use, When NOT to Use, Returns, Examples, Error Handling). It is slightly verbose but every sentence adds value. Front-loading the core purpose helps 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 the existence of an output schema (not shown), the description does not need to detail return values, but it still mentions the return format (one-line confirmation or error string). It covers error codes (400, 404) and provides a realistic example. This is complete for a mutation tool with nested features.
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 0% (the description does not repeat schema parameter docs), but the description adds meaning by explaining how parameters are used (e.g., features toggles ClickApps, admin_can_manage is Enterprise-only, multiple_assignees is a boolean). The example demonstrates a typical parameter combination. While not exhaustive, it compensates adequately.
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 actions: 'Rename a Space, change its color/privacy, or toggle its ClickApp features.' It uses specific verbs and clearly identifies the resource (Space). It distinguishes from sibling tools like clickup_delete_space and folders/lists tools, ensuring the agent understands this tool's 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'When to Use' and 'When NOT to Use' sections, listing specific scenarios and alternative tools (e.g., 'use clickup_delete_space' for deletion, 'use the folders/lists tools' for status overrides). This guidance helps the agent select the correct tool and avoid misuse.
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?
Annotations already indicate non-readonly and non-destructive mutation. Description adds that the guest gains visibility into every list and task in the folder, that Enterprise plan is required (403 error), and that confirmation or error string is returned. This goes beyond annotations to clarify exact behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with clear sections (purpose, when to use/not use, returns, example, errors). Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and an output schema, the description covers purpose, constraints (Enterprise plan), alternatives, error handling, and return format. It is fully adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has parameter descriptions, but description adds value by clarifying permission_level meanings (e.g., read=view) and providing a usage example. The include_shared parameter is not elaborated, but overall adds nuance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool shares a folder with an existing guest at a given permission level. It distinguishes from siblings by specifying folder-level access versus list or task, fulfilling a specific verb+resource purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (giving guest access to entire folder) and when not to use (use list or task alternatives). Also notes Enterprise plan restriction and provides error handling details, giving clear guidance on appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior with return_immediately parameter, background population for large templates, and error handling for 400 and 404. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections, examples, and error handling. Front-loaded with main purpose. Every sentence adds value; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: creation, async behavior, prerequisites (template discovery), error handling, and output format. Output schema exists and description explains return value. Complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions exist (e.g., for template_id, return_immediately), but description adds value by explaining template_id prefix, return_immediately default behavior, and the options parameter. With 0% schema coverage (per context), description compensates well. However, could be more concise about options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new List inside a Folder by instantiating a List template.' with specific verb and resource. Distinguishes from siblings by mentioning alternative tools in 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'When to Use' and 'When NOT to Use' sections with references to sibling tools like clickup_create_list_from_template_in_space and clickup_create_list. Also advises polling with clickup_get_list for large templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false) and not destructive. The description adds key behavioral details: with return_immediately=True, the returned List id may represent a List still being populated in the background for large templates, and recommends polling with clickup_get_list to confirm completion. Also covers error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, prerequisites, usage guidelines, return value, examples, and error handling. Every sentence adds value, and it is concise without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 adequately explains the return value (confirmation string with id or error). It includes prerequisites, behavioral notes on background population, and error codes. The tool's complexity is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with descriptions. The tool description adds context for template_id (prefix) and return_immediately (effect), but does not detail the options parameter; however, the schema covers it. Overall, the description complements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 folderless List inside a Space by instantiating a template. It distinguishes from siblings by naming alternatives like clickup_create_list_from_template_in_folder and clickup_create_folderless_list, and provides specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear context. It specifies scaffolding a folderless List with a known template, and warns against using when the space uses folders or when no template fits, directing to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior: reads local file, posts as multipart/form-data, file not echoed back. Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, consistent with mutation. No contradiction. Adds error handling details (ValidationError for path issues, 404 for wrong task ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (purpose, when to use, returns, examples, error handling). Front-loaded with core purpose. Slightly long but each section earns its place for a complex tool. Could be trimmed slightly but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage scope, alternatives, parameter behavior, return value, examples, error handling. No gaps given the tool's complexity and the presence of output schema (return values not needing further explanation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema descriptions: explains file_path must be local, filename defaults to basename, custom_task_ids usage with team_id. Examples demonstrate parameter combinations. Enhances understanding of how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Upload a local file to a task as an attachment (v2)'. It specifies the verb (upload), resource (local file to task), and version. Distinguishes from sibling tools like clickup_create_entity_attachment and clickup_get_entity_attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections. Lists alternatives: use clickup_create_entity_attachment for v3 or file-type custom fields, use clickup_get_entity_attachments for reading. Clear guidance on prerequisites like custom_task_ids requiring team_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that deletion is permanent and cannot be undone, and includes error handling (404). Annotations already mark destructiveHint=true, but the description adds cascading deletion context without contradiction.
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 well-structured with clear sections, front-loaded key action, and no wasted words. Every sentence provides 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 return type (confirmation or error), error handling, and irreversibility. With an output schema present, this is fully complete for a destructive delete 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 description includes an example usage for folder_id, but the schema itself already provides a clear description. The example and additional context slightly enhance 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 specific action 'Permanently delete a Folder and every List/Task inside it.' It uses strong verbs and resource, distinguishing it from siblings like delete_list or update_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?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, with an alternative (archive via clickup_update_folder). This leaves no ambiguity for the agent.
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?
Annotations already set `destructiveHint: true`, `readOnlyHint: false`, `idempotentHint: true`. The description adds that deletion is permanent, there is no undo via API, and it removes the List and all its Tasks. It also explains the 404 error condition. This provides meaningful context beyond the 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?
The description is well-structured with clear sections: main action, consequences, usage guidance, returns, example, and error handling. Every sentence adds value and is front-loaded with the essential purpose. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being destructive and having a single parameter, the description covers all necessary aspects: purpose, usage guidelines, behavioral transparency, error handling, and an example. It is self-contained and adequately prepares the AI agent for correct invocation, even without output schema content visible.
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 only parameter is `list_id`. The input schema already has a description: 'List id to permanently delete.' The description provides an example usage with a placeholder value, which aids understanding. However, it does not add extra semantic guidance beyond what the schema offers. Given the schema coverage is 0% (likely meaning no tool-level description in schema), the example compensates well, earning a 4.
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 List from the Workspace.' It specifies the resource (List) and action (delete), and distinguishes from sibling tools like `clickup_update_list` which is for archiving. This is a specific verb+resource that leaves 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes 'When to Use' and 'When NOT to Use' sections, advising to permanently delete and to archive instead for temporary hiding, naming the alternative tool `clickup_update_list`. It also recommends confirming with the caller before production 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?
Beyond annotations (destructiveHint: true), description elaborates on irreversible deletion, lack of archive endpoint, and error handling (404, 401/403). Adds context about consequences and 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?
Well-organized with sections (main action, when to use/avoid, returns, examples, error handling). Every sentence adds value, no fluff. Front-loaded with primary 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?
Covers all relevant aspects: consequences of deletion, alternatives, return value, error scenarios, and example. Output schema is described indirectly, and annotations cover safety.
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 0% (per context), but schema itself describes space_id. Description provides an example (param usage) and implicitly conveys meaning through context. For a single required parameter, this is 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 clearly states 'Permanently delete a Space and everything inside it,' using a specific verb and resource. It distinguishes from sibling delete tools by specifying it's for Space and mentions alternatives (folders/lists delete 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?
Explicit 'When to Use' and 'When NOT to Use' sections, naming alternatives (folders/lists delete tools). Also advises confirming with user due to irreversibility.
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?
Annotations already indicate destructiveHint and idempotentHint, but the description adds key behavioral details: URL encoding, confirmation string return, error handling (404), and the cascading removal from all tasks. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, concise sentences, and no redundant information. Every sentence adds value, such as the automatic URL encoding note and the return/error handling.
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 destructive nature and idempotency annotations, the description fully covers what the tool does, when to use it, return value, and error cases. The output schema exists but is not shown; however, the description mentions the return is a confirmation string, sufficing.
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 0% per context, so the description must compensate. It adds the detail that tag_name is URL-encoded automatically, which adds meaning beyond the schema's property descriptions. However, it does not elaborate on the space_id parameter 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 the verb 'Remove' and resource 'tag from a Space's palette', and distinguishes from the sibling 'clickup_remove_tag_from_task'. It covers the scope and effect.
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' sections provide clear context for when to invoke this tool vs alternatives, specifically naming 'clickup_remove_tag_from_task'.
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 that deletion is permanent, removes subtasks, cannot be undone via API, and describes error handling (404). Annotations already indicate destructive and idempotent, and the description adds specific consequences without contradiction.
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 well-structured with clear sections, each sentence adds value. It is concise yet comprehensive, with no redundant 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?
Covers all necessary aspects: purpose, permanence, prerequisites, error handling, and alternatives. With annotations and output schema present, the description is fully adequate for a delete 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?
Although schema description coverage is reported as 0%, the description explains custom_task_ids and team_id usage with an example. Some parameter details (like task_id format) are left to the schema, but overall adds 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 it permanently deletes a task, mentions the HTTP method, and distinguishes from close/archive (via sibling clickup_update_task). It is 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?
Provides explicit 'When to Use' and 'When NOT to Use' sections, directing users to use clickup_update_task for close/archive. Also explains custom_task_id usage and workspace id 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?
Discloses the irreversible nature of the deletion and provides error handling details (404 for non-existent IDs), adding to the destructiveHint annotation.
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?
Well-structured with clear sections, front-loaded key action, and no redundant 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?
Covers preconditions, return type, error handling, and irreversibility; complete given the tool's simplicity and 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 already covers param descriptions fully; description adds examples showing how to specify single or bulk IDs, adding minor extra 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?
Clearly states the tool deletes time entries, specifies the API endpoint, and distinguishes from other delete tools in siblings by specifically targeting time entries.
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' sections, including a direct alternative (clickup_stop_time_entry) for stopping a running timer.
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?
Annotations indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds context by explaining the relationship between steps_current and the range from create_key_result, noting the return is a confirmation string, and covering error handling for 404 and 400 statuses. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the main purpose, then provides usage guidance, return info, an example, and error handling. Every sentence adds value without redundancy, and the front-loading allows quick understanding.
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 an output schema (not shown but noted) and moderate complexity, the description covers return value (confirmation string), error conditions (404, 400), and example usage. It adequately equips an agent to use the tool correctly without requiring additional external knowledge.
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 includes descriptions for all parameters, so the baseline is 3. The description adds value by explaining the semantics of steps_current (relationship to the created key result's range) and note (attaching a progress comment), which goes beyond the schema's descriptions. The error handling also gives context for parameter validity (steps_current out of range). Therefore, score 4.
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 updates a Key Result's progress, note, name, owners, or task/list links, using the verb 'Update' and specifying the resource. It distinguishes from siblings like clickup_create_key_result by explicitly stating when not to use this tool, 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 includes explicit 'When to Use' and 'When NOT to Use' sections, naming alternative tools (clickup_create_key_result, clickup_update_goal) and specifying the context for usage: logging progress on a manual Key Result. This provides clear guidance for selecting the correct 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?
Annotations already indicate a write operation (readOnlyHint=false) that is not destructive (destructiveHint=false) and idempotent (idempotentHint=true). The description adds valuable context: only passed fields are sent (partial update), Enterprise plan restriction, and error codes (403, 404) with meanings. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (purpose, when to use, when not to use, returns, examples, error handling). Every sentence adds value, with no redundancy or fluff. It is concise yet comprehensive.
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 complexity (update on workspace with multiple editable fields), the description covers all necessary aspects: purpose, usage boundaries, return type (confirmation string or error), and error handling. The existence of an output schema (not shown) further complements the description.
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 descriptions for each parameter (e.g., admin: 'Whether the member should have admin privileges'), so the description does not need to repeat them. However, the description adds the crucial behavioral detail that only passed fields are sent, which enhances understanding. The example also clarifies 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 action (update a workspace member's username, admin flag, or custom role) and specifies the resource (workspace member). It distinguishes itself from the sibling tool for editing guests, providing clear differentiation.
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 lists when to use the tool (renaming, promoting/demoting admin, reassigning custom role) and when NOT to use it (altering guest permissions), with a direct reference to the alternative clickup_edit_guest_on_workspace. It also notes the 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?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds rich behavioral context: cursor-based pagination, error handling (404), and response structure (list of users with next_cursor), beyond what annotations provide.
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?
Well-organized into sections: purpose, usage guidelines, return format, pagination, examples, error handling. Every sentence is informative 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?
Covers all necessary aspects: purpose, when/not to use, parameter examples, pagination mechanism, error handling, and return format. With annotations and output schema present, the description is fully 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?
The input schema already has detailed descriptions for all parameters (limit, cursor, channel_id, workspace_id, response_format). The description supplements with usage examples and pagination notes, adding 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 clearly states the tool lists members of a chat channel with a specific verb ('list') and resource. It distinguishes from a sibling tool by explicitly noting when to use an alternative for subscribers.
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 when-to-use ('audit who has access') and when-not-to-use with a named alternative ('use clickup_get_chat_channel_followers for subscribers'), offering clear 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: cursor-based asymmetric pagination with loop instructions, error handling (401/404), and that results include only channels the user can see. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Returns, When to Use, When NOT to Use, Pagination, Examples, Error Handling). It is front-loaded with the main purpose. However, it is slightly verbose; some details could be more compact, but overall each sentence 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?
Given the tool's complexity (multiple filters, pagination, error handling), the description covers all essential aspects: return format, parameters, usage guidance, pagination loop, and error codes. It provides enough context for an agent to use the tool correctly without needing external resources.
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 explains the key parameters (channel_types, is_follower, include_closed, with_message_since) and how they narrow results. It provides concrete examples (e.g., channel_types=["CHANNEL"]). This adds meaning beyond the input schema's descriptions, which are already detailed but benefit from the narrative 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 the Chat channels in a Workspace, with descriptor filters.' It distinguishes from sibling tools like clickup_get_chat_channel (single channel) and clickup_get_chat_messages (messages), making the purpose and scope 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?
Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance. It tells when to use this tool (find channel id, enumerate DMs, filter followed channels) and when not to (reading messages, which belongs to clickup_get_chat_messages).
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: newest-first ordering, cursor-based pagination, return format (author, id, timestamp, reply count, content snippet), next_cursor handling, error codes (404, 401), and error output 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?
The description is well-structured with clear sections (main action, When to Use/Not Use, Returns, Pagination, Examples, Error Handling). It is front-loaded with the core purpose, and every sentence adds unique 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 presence of an output schema (so return values are documented elsewhere), the description provides comprehensive coverage: usage context, exclusions, pagination mechanics, concrete examples, and error handling, making it complete 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 already provides descriptions for all parameters (0% gap), baseline 3. The description adds practical context through examples and the pagination section, explaining how to use cursor and limit parameters, which elevates practical 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 'List the messages in a Chat channel (newest first), cursor-paginated,' which is a specific verb+resource. It explicitly differentiates from siblings like clickup_get_chat_channels and clickup_get_chat_message_replies in the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes both 'When to Use' and 'When NOT to Use' sections with specific alternative sibling tools, providing clear guidance on when to invoke this tool versus others.
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 return format (markdown/JSON), pagination details (cursor-based, same as clickup_get_task_comments), and error handling (404 for wrong/non-Chat view). No contradiction with annotations (readOnlyHint, etc.).
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?
Well-structured with clear sections (When to Use, When NOT, Returns, Pagination, Examples, Error Handling). Front-loaded with the main purpose. 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?
Comprehensive for a tool with only one required parameter and an output schema. Covers pagination, error cases, and provides an example. 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?
Schema coverage is 0% but the description provides detailed pagination explanation and an example. While it doesn't reiterate parameter names, it adds value beyond the schema for understanding 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 lists comments in a Chat view, newest first, and distinguishes it from sibling tools like clickup_get_chat_channel_messages for modern channels.
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 (legacy Chat views) and when not to use (modern Chat channels, directing to clickup_get_chat_channel_messages), giving clear alternatives.
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?
Adds details beyond annotations: Enterprise plan requirement, 403 error, explanation of inherited_role, response content, and error handling. Annotations already indicate safe read/ idempotent nature.
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?
Well-structured with headings and examples, but slightly lengthy. Front-loaded with main purpose. No redundant sentences.
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 low complexity, presence of output schema, and good annotations, the description provides sufficient context including error handling and usage examples.
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?
Despite 0% schema description coverage signal, description thoroughly explains team_id (not group_id), include_members, and response_format, adding clarity 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 'List the Custom Roles configured for a Workspace', specifies the API endpoint, and distinguishes from sibling tool clickup_get_user_groups for User Groups.
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?
Includes explicit 'When to Use' and 'When NOT to Use' sections, naming the alternative tool and noting Enterprise plan restriction.
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?
Beyond annotations (readOnly, idempotent), the description details cursor-based pagination, loop pattern, and specific error handling (404 meanings, 400 mismatches), providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use/not use, pagination, examples, error handling). Slightly verbose but efficient for the complexity; could be tightened but still strong.
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 complexity, zero schema coverage, and presence of output schema, the description covers return values, pagination, errors, and usage context comprehensively. No gaps identified.
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?
Although the input schema has 0% description coverage, the description elaborates on each parameter (entity_type options, cursor, limit, etc.) with examples and clarifies entity_id meaning, fully compensating for schema gaps.
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 attachments of a task or File-type Custom Field. It specifies the API endpoint and distinguishes from sibling upload tools, 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?
Includes explicit 'When to Use' and 'When NOT to Use' sections, directing to use for enumerating attachments and advising against using for uploads, with alternatives provided. Also covers fallback on 404 errors.
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 adds significant behavioral context beyond annotations: explains pagination windowing behavior (has_more, next offset), response format (markdown/json), and error handling (404). Annotations already declare readOnlyHint, idempotentHint, etc., so the description enriches the behavioral model.
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 well-structured with clear sections (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). It is front-loaded with the core purpose and 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?
Given the tool's complexity (pagination, format selection, sibling tools, error handling) and the presence of an output schema, the description covers all necessary aspects: usage context, behavioral details, parameter semantics, and troubleshooting. It is fully 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?
The input schema has descriptions for each parameter, so the baseline is 3. The tool description adds extra context in the 'Pagination' section and examples, clarifying how limit/offset and archived work. It provides more meaning than the schema alone, justifying a 4.
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 a clear verb+resource: 'List the Lists that live directly inside a Space (no Folder).' It explicitly distinguishes from siblings in the 'When NOT to Use' section, naming clickup_get_lists per folder and clickup_get_list as alternatives. This meets the highest standard.
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 clear when-to-use (enumerating folderless lists) and when-not-to-use scenarios (space uses folders, already have list_id), with specific alternative tool names. This is explicit and actionable.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: Enterprise plan only (403 on other plans), return format options (markdown or json), error handling for 403 and 404. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, note, when to use/not use, return format, example, error handling. It is concise yet comprehensive, with no redundant 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?
The description covers purpose, usage guidelines, return format, example, and error handling. Given the annotations and output schema presence, this is complete. The tool's complexity is low, and all necessary information 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?
The input schema already provides descriptions for `team_id`, `guest_id`, and `response_format`. The description adds example usage (`params = {"team_id": "123", "guest_id": "456"}`) and error-handling context that clarifies parameter semantics. The parameter count in context signals (1) is misleading, but the description compensates with clarity.
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 'Look up a guest's permission flags and what has been shared with them.' It specifies the verb (look up) and resource (guest), and distinguishes itself from the sibling tool `clickup_get_user` which is for full Workspace members.
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 includes 'When to Use' and 'When NOT to Use' sections, naming the alternative tool `clickup_get_user` for workspace members. It also notes the Enterprise plan restriction. This provides clear guidance on when to select this tool over others.
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?
Annotations already declare readOnlyHint=true; description adds ordering (newest first), return format, pagination details (cursor-based, omit for recent 25), and error handling for 404. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling). Front-loaded with main purpose, concise and 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?
Covers purpose, usage, parameters, pagination, error handling. References sibling for full pagination explanation. Has output schema, so return values not needed. Complete for a read tool with good annotations.
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 0%, so description must compensate. It explains list_id context, start/start_id usage via pagination section, and response_format via Returns. Adds 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?
The description clearly states 'List comments on a List's info panel, newest first.' It specifies the resource (List's info panel comments) and action (list), and differentiates from sibling clickup_get_task_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?
Explicitly provides 'When to Use' (read List-level discussion/status history) and 'When NOT to Use' (read task comments, use clickup_get_task_comments). Also references sibling for pagination pattern.
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?
Adds detail beyond annotations: explains inherited field scoping, response structure (id, type, type_config), and error handling (404, 401/403).
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?
Well-structured with sections for purpose, when to use/not use, returns, examples, and error handling; every sentence adds value without 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?
Complete given low complexity: covers scope, input, output, examples, errors, and sibling tools. Output schema exists, so return details are 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?
Despite 0% schema coverage, description explains each parameter's purpose (e.g., response_format markdown vs json) and provides usage examples, compensating for missing 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?
Description explicitly states it lists custom fields from a list, distinguishes from sibling tools like get_folder_custom_fields, get_space_custom_fields, and get_team_custom_fields by scoping.
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?
Clearly states when to use (before setting a value, to get field ID/options) and when not to use (for higher-level fields), naming 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?
Annotations already declare readOnlyHint=true, etc. Description adds beyond: pagination details (client-side slicing, MAX_DISPLAY_ROWS cap), error handling (401/403/404), and return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, returns, pagination, examples, error handling). No wasted words; every sentence adds necessary 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?
Covers purpose, usage, parameters, pagination behavior, error handling, and examples. Even with output schema present, the description provides enough context 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides descriptions for all parameters, but description adds value by noting the client-side capping of limit at 50 and showing a complete example. This extra context justifies above 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?
Opening sentence 'List the Spaces in a Workspace' is specific verb+resource. Later differentiates from 'clickup_get_space' for fetching a single space's detail, making purpose clear and distinct from sibling.
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' sections. States when to use (discovering spaces, checking archived) and when not (use `clickup_get_space` for single space detail), providing clear guidance and alternative.
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?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses the exact API method (GET), the fact that only direct members are returned (excluding groups and inherited access), error handling for 404 and 400 codes, and example parameter sets. This enriches the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise summary, followed by API details, usage guidance, return information, example usage, and error handling. Each section is brief and pertinent, with no superfluous 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?
Given the tool's simplicity (one required parameter, existing output schema, and rich annotations), the description covers all essential aspects: purpose, scope, usage guidelines, behavioral details, parameter examples, and error handling. It is complete for an agent to correctly select and invoke the 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?
Although the schema has detailed descriptions for each parameter, the tool description adds value through explicit examples and error conditions related to parameters (e.g., custom_task_ids requires team_id). However, it does not mention the response_format parameter, and the description's schema coverage is low (0%), so the description does not fully compensate.
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 the action 'List', the resource 'Workspace members with direct access to a Task', and the scope 'direct access only'. It distinguishes from sibling tools like clickup_get_list_members and clickup_get_task, clarifying what this tool does and does not do.
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 includes a 'When to Use' section for checking task visibility before sharing sensitive details, and a 'When NOT to Use' section with specific alternative tools (clickup_get_list_members for list-level access, task-detail tools for assignments). This provides clear decision-making guidance for the AI.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable operational details: pagination mechanics (page-based, up to 100 tasks per page, 'More available' signal), return format constraints (first 50 tasks rendered), and error handling (404 for wrong list id, empty result past end). 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?
The description is well-organized: a one-line summary, followed by clear sections for when to use/not use, returns, pagination, examples, and error handling. Every sentence serves a purpose, and key information is 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 the tool's complexity (many parameters, pagination, error cases), the description covers all essential aspects: scope, filtering, sorting, pagination mechanics, return format, and error handling. The presence of an output schema means return structure is covered elsewhere, so the description is appropriately 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?
The input schema provides descriptions for all parameters (100% coverage), so the description's role is to add value beyond that. It summarizes the filter surface (statuses, assignees, tags, etc.) and provides usage examples, which helps an agent quickly grasp the parameter landscape. However, the schema already documents each parameter, so the description adds moderate extra 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 'List tasks inside ONE List, with filters and sorting,' specifying the verb (list) and resource (tasks within a single list). It explicitly distinguishes from sibling tools by naming alternatives and their appropriate contexts.
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 includes dedicated 'When to Use' and 'When NOT to Use' sections with explicit references to alternative tools (clickup_get_filtered_team_tasks, clickup_get_task), 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description adds: the exact API endpoint, pagination details (page-based, 0-indexed), return format (markdown list or JSON), and error handling for missing team_id. This fully discloses 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 well-organized into sections (purpose, API call, when to use/not use, returns, pagination, examples, error handling). Each sentence serves a purpose, and it's concise yet comprehensive.
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 output schema exists (as per context signals), the description covers the return format and pagination. It also addresses error handling. For a read-only list tool, 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?
With 0% schema description coverage, the description must compensate. It explains team_id (fallback) and page (0-indexed), and mentions return format which relates to response_format. An example is provided. However, it doesn't explicitly list all parameters in a structured way, but still adds significant 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 'List the Workspace's saved task templates.', specifying the verb and resource. It distinguishes from siblings like get_folder_templates and get_list_templates by noting it's for workspace-level templates.
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 'When to Use' (discover template ids before creating a task) and 'When NOT to Use' (not for Folder/List templates, directing to other tools). This gives clear guidance and alternatives.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context: output format (Markdown or JSON), returned fields (id, name, type, parent), and error handling (404 for wrong team_id). 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?
The description is well-organized into clear sections (purpose, when to use/not use, returns, examples, error handling). It is concise with no unnecessary words, every sentence provides necessary 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?
Given the tool is a simple read operation with only two parameters, the description covers all essential aspects: scope, purpose, usage guidance, output structure, and error handling. The presence of an output schema reduces the need to document return values in detail.
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 describes both parameters (team_id and response_format) with descriptions. The description adds value by specifying default response_format as 'markdown', showing an example, and linking error handling to parameter values.
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 the task and page views defined at the Everything Level of a Workspace.' This verb+resource combination is specific and distinguishes from sibling tools like clickup_get_space_views, clickup_get_folder_views, and clickup_get_list_views.
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' sections guide the agent. It directs to sibling tools for other scopes and advises using this tool before calling view-related tools (clickup_get_view, clickup_get_view_tasks, clickup_update_view).
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?
Annotations already provide readOnlyHint and idempotentHint. The description adds details about response format (Markdown/JSON), fields (id, author, date, truncated text), pagination (full thread returned, no cursor), and error handling (404). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, examples, bullet points, and no extraneous information. It is thorough yet 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?
Given the tool's simplicity (one required parameter, read-only), the description covers return values, pagination, error handling, and output format options. It is complete for effective use.
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 describes comment_id and response_format with descriptions and default. The description adds an example (params = {'comment_id': '446750'}) and explains that response_format defaults to markdown, reinforcing 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?
The description clearly states 'List the replies in a comment's thread' and explicitly notes that the parent comment is not included. It distinguishes from sibling tools like clickup_get_task_comments by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes dedicated 'When to Use' and 'When NOT to Use' sections, naming specific alternatives (clickup_get_task_comments, clickup_get_list_comments, clickup_get_chat_view_comments) for top-level comments.
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?
Annotations (readOnlyHint, destructiveHint) are supplemented with useful behavioral details: negative duration means running timer, pagination capped at 50 rows, error handling for 404 and 429. 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?
Well-structured with sections (API call, when to use, returns, pagination, examples, error handling). Front-loaded with basic purpose. Comprehensive yet 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?
Covers all aspects: purpose, usage, return format, pagination, error handling. Output schema exists and description aligns. Complete for a read-only list 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 0% but description adds meaning: explains start_date/end_date requirement, scope filters, team_id default, and various boolean options. Could be slightly more systematic but compensates well.
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 time entries in a Workspace, scoped by date range and location. It distinguishes from siblings like clickup_get_time_entry (fetch by id) and clickup_get_running_time_entry (current running entry).
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' sections. Provides use cases (auditing, timesheet) and alternatives. Also details pagination behavior and display cap.
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 the destructive nature (source tasks consumed) and provides the API endpoint and response format, adding context beyond the destructiveHint annotation.
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?
Concise and well-organized: summary, technical detail, usage guidance, return value, example, error handling. No unnecessary 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?
Covers all necessary aspects: purpose, when/not to use, technical details, error handling, and an example. Output schema exists, so return format is adequately described.
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 has descriptions, but the description adds important nuance (Custom Task IDs not supported, internal ids required) that clarifies 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?
Clearly states the action (merge) and the resource (tasks), and distinguishes from sibling tool clickup_move_task by specifying when not to use it.
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 (consolidate duplicates) and when not to use (move between lists), with a direct reference to an alternative 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?
Annotations indicate destructiveHint: true, readOnlyHint: false. The description confirms it is a mutating operation and adds crucial context: it only removes the value, not the field definition. Error handling details further enhance 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 well-structured with clear sections (purpose, when to use/not use, return, examples, error handling). It is concise yet informative, 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?
Given the tool has multiple parameters and an output schema, the description covers all necessary aspects: operation, usage boundaries, return value, and error scenarios. It is complete for an agent to correctly select and invoke the 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 description adds meaning beyond the schema by providing concrete examples and clarifying the conditional requirement of team_id when custom_task_ids=true. The schema descriptions are already present, but the description's examples and error conditions add practical 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 the action: 'Clear a Custom Field's value on a task.' It specifies the HTTP method and endpoint, and distinguishes from sibling tools like clickup_set_custom_field_value and the deletion of the field itself.
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' sections with direct references to sibling tools. Also provides error handling guidance for 404 errors and the custom_task_ids constraint.
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 plan limitation (returns 403 on non-Enterprise) and error codes (403, 404), and describes return type (confirmation string or error string), adding value beyond annotations which only indicate destructiveHint=true.
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?
Well-structured with clear sections: main action, plan note, usage guidance, example, error handling. Each sentence is purposeful and there is 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 the tool's complexity (3 parameters, output schema present), the description covers purpose, usage constraints, error handling, and return type, making it sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an example of parameters, but the input schema already provides descriptions for all parameters. The description does not explain the 'include_shared' parameter, so it adds only marginal 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 clearly states the verb 'Revoke' and resource 'List', and explicitly distinguishes from sibling by stating when NOT to use (for single task removal, use clickup_remove_guest_from_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?
Provides explicit 'When to Use' and 'When NOT to Use' sections, including specific context about un-sharing a whole List while leaving other items intact, and notes the 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?
Beyond annotations (destructive, idempotent), description discloses prerequisite (Tasks in Multiple Lists ClickApp), error handling (403, 404), and return type (confirmation/error string). 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?
Well-structured with clear sections, front-loaded main action, no redundancy. Every sentence 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?
Given annotations, output schema exists, and tool complexity, description covers prerequisites, usage boundaries, error handling, and example. Complete for agent decision-making.
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?
Despite schema description coverage of 0%, the description provides examples and context for parameters, though the schema itself contains descriptions. Adds value with concrete example and error implications.
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 task's membership from an additional (non-home) list, using specific verbs and resources. It distinguishes from deleting a task entirely and from removing from the home 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?
Explicit 'when to use' (undoing add_task_to_list) and 'when NOT to use' (removing from home list) sections, including alternatives like deleting the task.
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 adds context beyond annotations: it clarifies that the tag is not deleted from the workspace, only the association is removed. It also explains error handling (404 for non-existent entries). Annotations declare destructiveHint=true and idempotentHint=true, and the description aligns without contradiction.
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 well-structured with clear sections: main action, API endpoint, clarification, when to use/not use, returns, example, and error handling. It is front-loaded with the core purpose and each 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?
Given the presence of an output schema and annotations, the description is complete: it explains the behavior, distinguishes from related tools, provides usage guidelines, and includes error handling. All essential aspects are covered.
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 description includes an example with params but does not explain each parameter in detail beyond what the input schema provides. The schema has descriptions for all parameters (despite context indicating 0% coverage), so the description adds moderate value through the example and context of use.
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 and resource: 'Remove one or more tags from one or more time entries.' It distinguishes from siblings like clickup_add_time_entry_tags and clickup_rename_time_entry_tag by explaining the specific action (removing association, not deleting the tag itself).
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 (untagging a batch without deleting the tag definition) and when NOT to use (to delete the tag everywhere, suggesting clickup_rename_time_entry_tag instead). This guides the AI agent appropriately.
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?
Description adds behavioral context beyond annotations by detailing return type (confirmation or error string), and error handling for 403 and 404. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections, front-loaded purpose, and no unnecessary words. 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 simplicity and the presence of annotations and output schema, the description covers all necessary aspects: purpose, usage, error handling, and restrictions. It is fully informative for an AI 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?
Input schema already provides descriptions for each parameter (team_id, user_id). The description adds an example of usage, which clarifies parameter formatting but does not add new semantic 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?
The description clearly states the tool deactivates a full member's access to a Workspace, using a specific verb and resource. It distinguishes itself from the sibling tool for removing guests.
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' sections, specifying an alternative tool for guests. Also notes the Enterprise plan requirement, providing clear decision criteria for the agent.
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 goes beyond annotations by detailing the side effect: 'this tool deletes the estimate for any assignee you don't include.' It also explains error codes (400, 404) and their meanings, and describes the return format. No contradiction with annotations (destructiveHint=true).
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 well-organized: purpose, HTTP call, plan note, usage guidelines, return description, examples, and error handling. Each section is concise and contributes to the overall understanding, with 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?
The description covers all necessary aspects: purpose, when to use/not use, side effects, error handling, and examples. Given the output schema exists, the description effectively supplements it with usage context and edge 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?
The input schema already provides descriptions for all parameters (e.g., time in milliseconds, assignee can be 'unassigned'). The description adds value by including examples that illustrate the parameter format (e.g., assignee as integer or 'unassigned') and emphasizing the replace semantics. While not necessary, the examples enhance clarity.
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: 'Overwrite a task's entire set of per-assignee time estimates.' It includes the HTTP call and distinguishes itself from the sibling tool clickup_update_time_estimates_by_user by explicitly noting the replace-all 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 explicitly states when to use ('resetting a task's whole per-assignee estimate breakdown') and when not to use ('to adjust just some assignees' estimates while leaving the rest untouched'), and names the alternative tool. It also mentions a prerequisite (Business Plan).
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?
Adds extensive behavior beyond annotations: POST method, polymorphic value shape, error handling (400, 404, custom_task_ids requirement), return type (confirmation string), and distinction between labels and tasks/people field types. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (header, endpoint, value table, usage, return, examples, error handling). Minor redundancy in examples, but overall organized and front-loaded with key purpose. Slightly verbose but 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?
Given the complexity of polymorphic value shapes and many field types, the description covers all necessary aspects: prerequisites, error handling, parameter dependencies, and output. Output schema exists but description provides sufficient return info ('confirmation string').
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?
Despite 0% schema description coverage, the tool description provides a full value shape table, examples, and parameter relationships (e.g., team_id required when custom_task_ids=true, value_options for date fields). Compensates fully for schema gaps.
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 'Set a Custom Field's value on a task' and specifies the endpoint. It distinguishes from sibling tools like clickup_remove_custom_field_value and notes when to use alternative tools for bulk operations. The verb and resource are explicitly defined.
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 'When to Use' and 'When NOT to Use' sections, referencing alternatives like clickup_remove_custom_field_value for clearing and task create/update tools for multiple fields. Also mentions prerequisites such as resolving field_id via clickup_get_list_custom_fields.
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?
Goes beyond annotations by disclosing that duration in response is negative while running, that ClickUp allows only one active timer per user, and the 400 error scenario. Annotations (readOnlyHint=false, destructiveHint=false) are consistent.
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?
Well-structured with sections: summary, endpoint, when to use, when not to use, returns, example, error handling. Front-loaded and 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?
For a tool with complex input (nested object), output schema, and annotations, the description covers purpose, usage, behavior, returns, and error handling. It is fully adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has descriptions for each property, but the description adds a concrete example (params = {team_id: '123', tid: 'abc123', description: 'pairing session'}) which helps understanding. Schema coverage is 0% but schema itself has descriptions, so baseline is 3, and the example adds 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?
Clearly states it starts an open-ended running timer for the authenticated user. Differentiates from sibling clickup_create_time_entry by specifying the open-ended nature versus timers with known duration. Also mentions the API endpoint.
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 'When to Use' (beginning live tracking with no known end) and 'When NOT to Use' (log known duration, check for active timer first with clickup_get_running_time_entry). Also covers error handling (400 indicates timer already running, use clickup_stop_time_entry).
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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses Enterprise-only restriction (403), billing implications, permission level mapping (1=read, 3=comment, etc.), and error handling (403/404). This adds significant 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 well-organized into sections (main, when to use, when not, returns, examples, error handling), front-loads core purpose, 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?
For a complex tool with nested ACL entries and privacy toggle, the description covers plan restrictions, billing, error codes, supported object types, and provides examples. Output schema exists, so return values are not needed. The description is comprehensive for agent decision-making.
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?
With 0% schema description coverage (by context signals), the description explains the entries structure, permission level mapping, and null usage for removal. It provides two examples illustrating parameter combinations. However, workspace_id default behavior is not mentioned, and schema already has descriptions for some fields.
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 sets privacy and grants/revokes access, with specific verb 'Set' and resource 'privacy of an object and grant/revoke user or group access'. It lists supported object types, distinguishing from sibling tools like workspace invitation tools via the 'When NOT to Use' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide concrete examples (e.g., making a List private, revoking access) and direct the agent to alternative tools (guests/users tools) for workspace invitations, making usage boundaries very clear.
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 the API call, return type (confirmation string), and error handling (400, 404). Complements annotations: non-destructive, idempotent update operation. 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?
Well-structured with clear sections: purpose, when to use/not, returns, examples, error handling. Every 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?
Covers usage boundaries, error cases, and examples comprehensively. The output schema exists but is not needed due to the clear return description. Fully 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by showing example usage patterns and clarifying constraints like start/end pairing and tag_action rules. Schema already includes descriptions for most parameters, but the description provides real 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 'Edit an existing time entry's description, tags, times, task, or billable flag.' Specific verb and resource, and distinguishes from siblings by naming alternatives for tag management and timer stopping.
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 lists when to use (correcting logged entries) and when NOT to use, referencing sibling tools clickup_rename_time_entry_tag, clickup_remove_time_entry_tags, and clickup_stop_time_entry.
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?
Beyond annotations (non-read-only, idempotent, non-destructive), description reveals full replacement semantics, re-enable behavior for suspended webhooks, and error handling (400/404). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, returns, examples, and error handling. Every sentence is informative; 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?
Covers return format ('confirmation naming webhook id and changed fields'), error cases, prerequisites (use get_webhooks to read current values), and examples. Output schema exists but description still provides clarity.
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 describes parameters (events, status, endpoint, webhook_id). Description adds value by explaining replacement behavior and need to re-supply unchanged fields, though examples and prose reinforce 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?
Description clearly states 'Change a webhook's endpoint, event subscription, or delivery status' with specific verb and resource. Differentiates from siblings by naming clickup_create_webhook and clickup_delete_webhook.
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' sections with specific scenarios like re-pointing a webhook or reactivating a suspended one. Provides 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?
The description explains the dependency creation behavior in detail, including direction mutual exclusivity, required parameters, and return value. It also covers error handling (400/403/404) for common issues. Annotations are non-contradictory and the description adds significant behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections, front-loaded with the core purpose, and each sentence adds value. It is concise yet comprehensive, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (confirmation), the description appropriately mentions the return value. It also covers error handling and provides examples, making it complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite context indicating 0% schema description coverage, the description adds essential parameter semantics: explains mutual exclusivity of depends_on/dependency_of, clarifies custom_task_ids usage, and gives concrete examples. This compensates fully for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 blocking dependency between two tasks.' It explains the concept of dependency direction and distinguishes from related tools like clickup_add_task_link and clickup_delete_dependency, ensuring the agent understands exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear context: enforce execution order or surface blockers, and contrast with clickup_add_task_link for loose associations and clickup_delete_dependency for removal. Examples further guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the placement behavior (optional parent_id/parent_type) and default location. It also describes error responses. Annotations do not contradict; the tool's behaviors are fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear sections, and front-loads the primary action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's parameter count and complexity, the description is complete: it covers usage, placement logic, alternatives, returns, error handling, and examples. Output schema is said to exist, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already provide meaning for each parameter. The description adds valuable context like the numeric enum mapping for parent_type and the default behavior for missing parent fields, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Doc, optionally placing it in a specific location. It distinguishes from siblings like clickup_create_page and clickup_edit_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools. Examples and error handling further guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses important behaviors: Custom Fields added at this level apply to every task and prevent moving the view, error handling for 404/403, and confirmation string return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use/not use, returns, examples, error handling), every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for the tool's complexity: it covers purpose, usage boundaries, parameter nuances, return type, and error scenarios, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to parameters, especially the 'columns' field with its permanent effect, and provides an example usage. Schema descriptions are also present, but the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 view at the Everything Level of a Workspace, distinguishing it from other view creation tools by explaining the cross-Space scope and when to use alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' sections provide clear guidance, naming specific sibling tools (clickup_create_space_view, clickup_create_folder_view, clickup_create_list_view) for different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds value by explaining the API call details, return value, and warning about billing implications for adding view-only guests. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: API explanation, usage guidelines, return value, examples, error handling. It is detailed but not verbose, and front-loads essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (parameter naming confusion, billing implications) and the presence of siblings, the description covers all necessary aspects: purpose, usage, parameters, behavior, errors, and examples. Complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description compensates by explaining the meaning of each parameter (team_id is workspace id, members are user ids, handle for @mentions, etc.) and provides an example. It adds clarity beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 User Group (called a Team in ClickUp's endpoint), specifies the HTTP method and path, and clarifies the confusing terminology (team_id vs group_id). It distinguishes from siblings like clickup_update_user_group and clickup_delete_user_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, providing clear guidance on when to use this tool vs alternatives (e.g., use clickup_update_user_group for adding/removing members). It also mentions error handling and billing impact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: requires 'Total time in Status' ClickApp, explains error handling (client-side rejection, empty results meaning disabled app), and describes return format choices.
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?
Well-organized with sections, no wasted words, every sentence provides 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?
Covers purpose, usage boundaries, prerequisites, error handling, return format, and example. Fully sufficient given the tool's complexity and existing annotations/output schema.
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?
Description adds context to schema parameters: explains API call structure (repeated query param), how to use custom_task_ids with team_id, and provides an example. Schema descriptions are already detailed, so additional value is present.
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 'Report time-in-status for 2 to 100 tasks in one call.' and distinguishes from the sibling single-task tool by name and use case.
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' sections, including the specific alternative tool name and the minimum count 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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that the default 'Task' type (id 0) is not returned, and explains what the response contains. 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?
The description is well-organized into sections with headers, bullet points, and code examples. It is informative without being verbose, each 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?
With an output schema present, the description explains return formats (markdown list or raw JSON) and error codes. It covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description fully explains the purpose and expected values of both parameters (team_id and response_format), including defaults and examples. It compensates entirely for the lack of 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 it lists custom task types (custom items) for a Workspace, names the HTTP endpoint, and distinguishes from other tools by focusing on custom items. It is 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 provides 'When to Use' and 'When NOT to Use' sections, gives concrete examples, and includes error handling guidance. This makes it easy for an agent to decide when to invoke 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?
Beyond annotations (readOnlyHint=true, etc.), the description discloses pagination details (no server-side paging, cap at 50, truncation note), return format options, inline key results summary, and error handling (404 for bad team_id, 401 for invalid token). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use/not use, returns, pagination, example, error handling). Every sentence adds value, and it is front-loaded with the most important 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 complexity and the presence of an output schema, the description covers purpose, usage contrast, pagination behavior, error handling, and parameter details. It is sufficiently complete for an agent to select and invoke the tool correctly.
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?
Despite schema description coverage being 0%, the description fully explains all three parameters: team_id (defaults to CLICKUP_TEAM_ID), response_format (markdown/json), and include_completed (default false). It also provides a usage example, adding significant meaning 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 'List the Goals in a Workspace, including any Goal Folders.' It uses a specific verb ('list') and resource ('Goals'), and explicitly distinguishes from the sibling tool clickup_get_goal, which fetches a single goal's detail.
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 'When to Use' and 'When NOT to Use' sections, including contrasting with clickup_get_goal. It also advises using include_completed=false to reduce result set size, giving clear guidance on tool selection.
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?
While annotations already indicate read-only, idempotent, and non-destructive traits, the description adds substantial behavioral details: pagination mechanism (server returns all, client windows with limit/offset), return format selection (markdown or json), and error conditions (401/403, missing env var). This goes well beyond the 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?
The description is well-structured with clear sections (intro, when to use, when not to use, returns, pagination, examples, error handling). Every sentence adds value, and it is front-loaded with the essential 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 has an output schema (so return values are documented elsewhere), the description covers all necessary context: purpose, usage guidance, parameter semantics, pagination, and error handling. It is complete for an agent to use this tool effectively.
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 input schema has parameter descriptions, but the tool description compensates for the low schema description coverage (0%) by explaining the meaning and usage of each parameter, including the fallback for team_id, windowing behavior for limit/offset, and response_format control.
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 available List templates for a Workspace' and distinguishes the tool from siblings by explaining that its output feeds specific creation tools. It also contrasts with the 'when NOT to use' case, 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?
Explicitly provides 'When to Use' and 'When NOT to Use' sections, directing the agent to other tools (clickup_create_list_from_template_in_folder/_in_space) when the template_id is already known. Also includes error handling guidance for missing 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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable details about return format (markdown or json), custom task ID behavior, and error handling (404 meaning wrong id), going beyond what annotations provide.
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 well-organized with clear sections, front-loading the core purpose. Every sentence adds value, and the structure makes it easy to scan for 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?
Covers all necessary aspects: purpose, usage conditions, alternatives, parameter details, return values, and error scenarios. Given the tool's simplicity and the presence of an output schema, the description is fully sufficient.
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 explains the interplay between custom_task_ids and team_id, offers examples for both standard and custom ID usage, and clarifies the response_format parameter. This adds significant context beyond the schema descriptions, especially given that schema description coverage is 0% per context signals.
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 'Fetch one task by id' and distinguishes itself from sibling tools by specifying when to use alternatives like clickup_get_tasks and clickup_get_filtered_team_tasks. It provides a specific verb and resource, 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?
Explicitly includes 'When to Use' and 'When NOT to Use' sections, naming alternative tools for browsing or searching multiple tasks. Examples and error handling further guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description significantly adds detailed behavioral context: it explains the return format (markdown or JSON), the fields included, and crucially, the cursor-based pagination mechanism with fixed page size, how to page older comments, and that the markdown output surfaces cursor values for looping. This goes well beyond the 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?
The description is well-organized with sections for purpose, API call, when to use/not, returns, pagination, examples, and error handling. Every sentence is informative and necessary. No redundancy or fluff. The structure aids 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 the tool's complexity (pagination, multiple optional parameters) and the presence of an output schema, the description covers all critical aspects: purpose, usage boundaries, return fields, pagination mechanics, error handling, and examples. It is fully 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0% (per context signals), the description provides rich usage semantics for parameters. It explains how start and start_id work together for pagination, with examples and clear rules. It also mentions the response_format parameter indirectly by describing the output. This adds meaning beyond the input 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 'List comments on a task, newest first' and specifies the API call. It distinguishes itself from the sibling tool clickup_get_threaded_comments, which is for reading replies. The verb 'list' and resource 'comments on a task' are 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?
The description includes explicit 'When to Use' and 'When NOT to Use' sections, directing agents to use this tool for reading discussion history and to use clickup_get_threaded_comments for threads. It also covers pagination and error handling, providing comprehensive usage 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?
Annotations already indicate read-only and idempotent behavior. The description adds critical context: the prerequisite ClickApp, return format (Markdown/JSON), and error conditions (empty result vs 404). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (usage, returns, examples, errors). Every sentence adds value, and the information is 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 the tool's simplicity, the description covers all aspects: purpose, prerequisites, usage boundaries, parameter hints, example, error handling, and return format. Output schema exists, so return values need not be detailed.
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?
Although schema coverage is 0%, the description supplements parameter meaning by explaining the interplay of custom_task_ids and team_id, and mentions response_format indirectly. Schema descriptions also exist for 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?
The description clearly states the tool's purpose: 'Report how long one task has spent in each status.' It specifies the API endpoint and distinguishes itself from the sibling tool 'clickup_get_bulk_tasks_time_in_status', making its scope unmistakable.
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' sections are provided, along with a concrete alternative tool. Examples and error handling further guide usage.
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 adds significant behavioral context beyond annotations, including the invariant seven config blocks returned, dependency on view type, and error handling (404). This complements the readOnlyHint and idempotentHint annotations without contradiction.
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 well-structured with clear sections (purpose, usage, returns, example, error handling) and is appropriately concise. 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?
The description is complete for the tool's complexity, covering what it does, when to use it, what it returns (including config blocks and formats), error handling, and its role as a precursor to clickup_update_view. The presence of an output schema further supports completeness.
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?
Despite schema description coverage of 0%, the description compensates by explaining the view_id parameter's role and the response_format parameter's effect, along with the default value. The example param block further clarifies 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 'Get the full configuration of a single task or page view,' specifying the verb, resource, and scope. It distinguishes from sibling tools like clickup_get_team_views and clickup_get_view_tasks by explicitly stating what it does not do.
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 includes dedicated 'When to Use' and 'When NOT to Use' sections, listing specific scenarios and naming alternative tools such as clickup_get_team_views and clickup_get_view_tasks, providing clear guidance for selection.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds crucial behavioral details: pagination behavior (page, up to 100 tasks, last_page check), return format options, and error handling (404 for wrong view_id). 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?
Well-organized with sections for summary, distinction, usage, returns, pagination, examples, and error handling. Every sentence adds value without redundancy. Concise yet comprehensive.
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 required param, clear annotations, output schema), the description covers all necessary aspects: behavior, pagination, output format, error handling. It is fully self-contained.
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 input schema provides basic descriptions, but the description adds significant context: how pagination works (increment page, check last_page), the meaning of response_format, and error handling for view_id. This goes well 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 what the tool does: 'List the tasks currently visible in a view, honoring its filters and sorting.' It also distinguishes itself from sibling tools like clickup_get_tasks and clickup_get_filtered_team_tasks, 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?
Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance, including naming alternatives (e.g., clickup_get_filtered_team_tasks). This helps an agent choose correctly.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds specific details: calls GET /user, reports token ownership, returns OK summary or error string, and explains error meanings. 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?
The description is well-structured with clear headings and concise sentences. Every sentence adds value, with no redundancy. It is front-loaded with the most important 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 zero-parameter tool, the description fully covers connectivity verification, authentication check, return format, error handling, and alternative tools. Given annotations and no output schema concerns, it 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?
No parameters; schema coverage is 100% (empty). Description does not need to add parameter details, and it correctly focuses on behavior and 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 explicitly states 'Verify connectivity and authentication against the ClickUp API' and further details the underlying endpoint. It clearly distinguishes from siblings by being a health check tool, not a data retrieval or mutation 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?
Provides explicit 'When to Use' (first call after configuring server, debugging 401/403) and 'When NOT to Use' (not for looking up other people, using members tools instead). Includes error handling 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?
Beyond annotations (readOnlyHint false, destructiveHint false, idempotentHint true), the description discloses endpoint details, member update shape, error codes (404, 403), and a billing warning for adding view-only guests. This adds significant 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 well-structured with sections (purpose, when to use, when not to use, returns, examples, error handling). Every sentence adds value; no filler. It is 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?
Given the tool's complexity (rename, handle, add/remove members, error handling, billing impact), the description covers all essential aspects. It references sibling tools and provides an output description. Nothing is missing.
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?
Despite 0% schema description coverage for the top-level parameter, the description explains the meaning of group_id (not a team_id), clarifies how add_member_ids and remove_member_ids work via examples, and provides usage context beyond the schema's property 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 explicitly states 'Rename a User Group and/or add/remove its members', providing a specific verb and resource. It differentiates from sibling tools like clickup_create_user_group and clickup_delete_user_group by outlining when to use and when not to use.
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 includes clear 'When to Use' and 'When NOT to Use' sections, explicitly naming alternatives (clickup_create_user_group, clickup_delete_user_group) and providing context for when this tool should be chosen.
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-mcp MCP server](https://glama.ai/mcp/servers/trustxai/clickup-mcp/badges/card.svg)](https://glama.ai/mcp/servers/trustxai/clickup-mcp)

Score Badge

Copy to your README.md:

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

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/trustxai/clickup-mcp'

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