ClickUp MCP Server

by asaphe

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with detailed descriptions that clarify scopes (e.g., get_task vs get_sprint_tasks vs get_list_tasks vs search_tasks). Even the sprint-specific create/get tools are clearly delineated from their general counterparts, and docs tools distinguish metadata, single-page, and all-pages retrieval. No two tools appear to do the same thing.
Naming Consistency4/5
The overwhelming majority follow a consistent snake_case verb_noun pattern (get_task, create_task, update_doc_page, list_teams). The only notable deviation is task_url, which is a noun phrase rather than a verb-led name, though its purpose is still clear. Overall, the naming is predictable and readable.
Tool Count2/5
At 28 tools, the set exceeds the 25-tool threshold where it becomes too heavy, even though it covers multiple domains (tasks, sprints, docs, teams). The count feels bloated; several tools are convenience wrappers (e.g., get_my_tasks, create_sprint_task) that could potentially be merged or documented as optional add-ons without sacrificing functionality.
Completeness4/5
The tool surface provides strong CRUD and workflow coverage for tasks (create, get, update, delete, search, list, move, bulk update, comments, tags) and sprints (current sprint, tasks, report). Docs have create and update, but no delete or share tool (noted as API/UI limitations). Minor gaps include no remove-tag tool and no direct way to update doc metadata beyond page content, but these are workable.
Average 4.5/5 across 28 of 28 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false, but the description adds no behavioral context. It does not explain what happens if the tag already exists, whether the operation is idempotent, or any permission requirements. With minimal annotations, the description fails to carry the burden of behavioral transparency.
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 exceptionally concise and front-loaded with the primary purpose. The Args section is minimal but not wordy. It could be slightly more informative without sacrificing efficiency, but it earns a high score for its lean structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation with a non-destructive annotation and an output schema, the description is mostly adequate. However, it omits contextual details such as error behavior (e.g., task not found, duplicate tag) and whether the tag is validated or auto-created. The output schema reduces the need to describe return values, but operational context is still thin.
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%, so the description must compensate. It provides brief explanations for both parameters: task_id accepts a custom ID like DEV-1234 or UUID, and tag_name is the tag to add. This adds meaning beyond the bare schema, though it does not elaborate on constraints or tag naming rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 function with a specific verb and resource: 'Add a tag to a task.' This distinguishes it from sibling tools like add_task_comment or delete_task. There is no ambiguity about what the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_task or ensure_task_fields. There are no exclusions, prerequisites, or context about using tags effectively. The only implicit guidance comes from the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the basic action. It does not mention side effects (e.g., removal from the old list), validation behavior, or reversibility. Annotations provide destructiveHint false, but the description itself offers negligible additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-purpose sentence followed by a clear argument list. No extraneous words or repetition, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation, the description covers purpose and parameters. However, it omits potential side effects, error conditions, or prerequisites, which could matter. Given the presence of annotations and output schema, the absence of these details makes it adequate but not 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 Args section adds meaningful semantics beyond the schema. It clarifies that task_id can be a custom ID like DEV-1234 or a UUID, and describes list_id as the target list. This helps the agent understand acceptable formats and intent, though it could be even more specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Move a task to a different list.' This specifies the verb (move), object (task), and result (different list), distinguishing it from siblings like update_task or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as update_task if list changes are supported there. It lacks any context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint=false and destructiveHint=false, leaving the mutating nature unclear beyond the verb 'add'. The description does not disclose additional behavioral traits such as whether the comment is appended or replaces existing comments, how invalid task IDs are handled, or any permission requirements. With minimal annotation coverage, the description carries a heavy burden it fails to meet.
Agents need to know what a tool does to the world before 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 a single opening line and a clean parameter list. Every sentence adds value, and it is front-loaded with the purpose. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 flat parameters) and an output schema exists, so return details are unnecessary. The description covers the operation and parameter semantics sufficiently for a straightforward write action. Missing context like task existence validation or idempotency is minor given the simplicity.
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 no descriptions (0% coverage), but the description fully compensates by explaining both parameters: task_id format (custom like DEV-1234 or UUID) and comment_text (plain text). This goes beyond the schema and is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a comment to a task, using a specific verb ('add') and resource ('task'). It is distinct from sibling tools like get_task_comments (reading) and update_task (modifying task properties), so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case clearly: when you need to attach a comment to a task. It does not explicitly mention alternatives or when not to use it, but the operation is self-evident, making the usage context clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it is a safe, read-only operation. The description adds the default-space behavior and the audit scope, but does not go much beyond that. It neither contradicts the annotations nor adds rich behavioral context, matching a 3 per the calibration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for the core purpose and one for the parameter. It is front-loaded, has no fluff, and every sentence earns its place. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is sufficient. It explains the purpose and parameter clearly, and the annotations plus output schema cover the rest. A minor gap is not explaining what 'configured team label IDs' refers to, but this does not severely hinder understanding.
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 for space_id has no description (0% coverage), but the description's Args section compensates by explaining that space_id is the space to check and that it defaults to the configured development space. This adds meaningful context beyond the schema's type/default 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 begins with a specific verb+resource: 'Audit configured team label IDs against live ClickUp field options.' This clearly distinguishes it from sibling tools like add_tag_to_task or list_teams, and conveys a precise purpose (auditing label configurations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool should be used to verify or audit label ID mappings, and the audit scope is stated. However, it does not explicitly mention when not to use it or point to a specific alternative, so it earns a 4 rather than a 5.
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?
Annotations already declare readOnlyHint=true, and the description does not contradict this. However, the description adds little behavioral context beyond the annotation—no mention of pagination, ordering, or other runtime behaviors. The task_id format note is parameter-focused, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, and the Args section is minimal and clear. Every word earns its place; no filler or 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?
This is a simple read-only tool with a single parameter and an output schema. The description covers the purpose and parameter format, and since the output schema exists, return value details are not needed. It 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (task_id) with no description (0% coverage). The description compensates fully by explaining the format: 'Task ID (custom like DEV-1234 or UUID).' This adds meaningful syntax guidance that is not available from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('all comments on a task'), clearly distinguishing this from siblings like add_task_comment and get_task. The purpose is unambiguous and concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all comments for a task) but does not explicitly mention alternatives or exclusions. There is no guidance like 'use add_task_comment to add comments' or 'for task details, use get_task', so it lacks explicit usage differentiation.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only safety profile is fully covered. The description adds useful context about the ID provenance (from create_doc/update_doc_page) and the content_format values, but does not disclose additional behavioral traits like pagination, rate limits, or return structure. This is adequate but not exceptional given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose statement, a usage guideline sentence, and a structured Args list. Every sentence adds value, and the information is front-loaded. The formatting is clean and easy to scan.
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 tool with only 3 parameters (2 required), an output schema, and strong annotations, the description is complete. It covers purpose, parameter semantics, and usage context. Return values are not described, but the output schema exists, so that is acceptable. No significant gaps remain.
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%, so the description must compensate. The Args section does this by explaining that doc_id and page_id are 'as returned by create_doc', and content_format lists allowed values ('text/md' default or 'text/plain'). This goes beyond the schema, which only specifies types and a default without allowed values. It is a helpful compensation 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's function: 'Get a single Doc page's content.' The verb 'Get' and resource 'Doc page' are specific, and 'single' distinguishes it from the sibling tool get_doc_pages which likely retrieves multiple pages. It also references the doc_id/page_id pair pattern from update_doc_page, further clarifying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'most useful when you already have both IDs from a prior create_doc/update_doc_page call.' This tells the agent when to use this tool, but it does not explicitly contrast with alternatives like get_doc_pages or get_doc, nor does it state when not to use it. Thus it has clear context but lacks exclusions.
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 signal readOnlyHint=true, so the description builds on that by disclosing default behaviors for include_closed and subtasks. The note that subtasks default inverted relative to search_tasks is a valuable behavioral nuance 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 tight: one introductory sentence followed by bullet-point argument explanations. Every line carried actionable information without redundancy or filler.
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?
It covers parameter semantics and tool relationships well, including a note about search_tasks' default. However, it omits details like pagination or sorting behavior, though an output schema exists and may cover return structure.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, provided examples for status, and highlighting the discovery path for list_id. It adds meaning the schema entirely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Get all tasks in a specific list' with concrete list type examples (backlog, epic, tech debt). This clearly distinguishes it from broader search tools like search_tasks and gives a precise verb+resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for list-scoped queries and cross-references get_workspace_hierarchy for list ID discovery, but it never explicitly states when to prefer this tool over alternatives like search_tasks or get_sprint_tasks. No exclusion criteria are provided.
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, so the read-only nature is covered. The description adds behavioral detail that both direct sprint list tasks and tagged tasks are returned, which is beyond the schema. No contradictions with annotations; however, it doesn't mention ordering or pagination, though that's less critical for this simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: a clear purpose statement, a scope clarification, and parameter explanations. It is front-loaded with the main action and contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema present, the description covers purpose, scope, and parameters. Minor gap: it doesn't state behavior when no current sprint exists or whether the output is exhaustive, but these are edge cases given the richness of sibling tools and context.
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?
Both parameters (assignee, status) are described in the tool description with usage details: 'me' for current user and example statuses like 'in progress'. Since the schema has no descriptions (0% coverage), the description fully compensates and adds meaning beyond the raw 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 tasks in the current sprint, optionally filtered' with a specific verb and resource. It also adds scope detail by mentioning both direct sprint list tasks and tagged tasks, distinguishing it from sibling tools like get_sprint_report or get_my_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current sprint tasks but does not explicitly contrast with alternatives such as get_sprint_report or get_list_tasks. There are no exclusions or 'use when' guidance, so while the context is clear, it lacks explicit alternative 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 already include destructiveHint: true, but the description adds value by warning to double-check task_ids and disclosing that partial failures are possible. It also clarifies that the same update is applied to all tasks, which is a behavioral nuance beyond the annotation.
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 reasonably concise and front-loaded with the critical warning. The Args section is structured and readable. Minor redundancy exists ('Verify' and 'Double-check' repeat the same point), but overall 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?
Given the tool has an output schema (not shown) and is a bulk mutation, the description covers key aspects: purpose, partial failures, and parameter semantics. It lacks explicit guidance on error handling for invalid IDs, but the partial failure note covers the main risk. Overall, it provides sufficient context for an agent to use it 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?
Schema description coverage is 0%, so the description carries the full burden. It provides clear, meaningful explanations for all five parameters: task_ids (custom or UUID), status, assignee_add (user ID), team (Component/Team label), and points. Each param is explained in context of the bulk operation, which is more helpful than a generic 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 a specific verb ('Update') and resource ('multiple tasks'), distinguishing it from the sibling tool 'update_task' which handles single tasks. It also notes it's a 'convenience tool' applying the same update to multiple tasks, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it ('multiple tasks at once') and warns to verify task IDs before calling, indicating a pre-check. It doesn't explicitly name alternatives, but the context of bulk vs. single update is clear. It also mentions partial failures, which helps set expectations.
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 and idempotentHint=true, so the description doesn't need to restate that this is a safe read operation. It adds valuable behavioral context by specifying accepted ID formats (custom like DEV-1234 or UUID), which is 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 succinct and well-structured. The first sentence states the purpose, and the Args block adds parameter details without redundancy. Every element earns its place, and there is no unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, strong annotations, and an output schema. The description fully covers the input semantics and the tool's action. There is no missing context needed for an agent to select and invoke this 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?
The schema has a single task_id parameter with no description (schema description coverage 0%). The description compensates fully by explaining the parameter: 'task_id: Task ID (custom like DEV-1234 or UUID).' This provides clear meaning beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Get the ClickUp URL for a task.' It is specific about the action (getting a URL) and resource (task), and the mention of custom IDs vs UUIDs adds useful distinctiveness from sibling tools like get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a task URL is needed, but it does not explicitly state when to use this versus alternatives like get_task or search_tasks. No exclusions or alternative references are provided, so the usage guidance is implied rather than explicit.
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 the annotations: it clarifies that only specified fields are changed, distinguishes replace vs append for description, and discloses that setting parent_task_id moves the task to the parent's list. It does not mention permissions or side effects, but the provided context is meaningful and does not contradict the annotations (openWorldHint=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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured: a one-sentence summary followed by a documented parameter list. Every line adds value, and the length is justified by the tool's 10 parameters. It is front-loaded and easy to scan.
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 (10 parameters, 0% schema coverage, output schema present), the description fully covers all parameters and key behaviors. It explains valid values, side effects, and relationships between parameters. The presence of an output schema means return value details are not required, so the description is complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining parameters. It does so thoroughly, providing format examples for task_id, value mappings for priority, and clarifying the behavior of description vs append_description, assignee_add/remove, and parent_task_id. This goes far beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields on a task. Only specified fields are changed.' This uses a specific verb and resource, and the partial-update semantics distinguish it from related tools like create_task, delete_task, and bulk_update_tasks. The explicit list of updatable fields further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for single-task updates but does not explicitly mention alternatives like bulk_update_tasks or ensure_task_fields, nor does it state when not to use this tool. It does provide guidance on using append_description instead of description for appending, and notes the reparenting behavior, but lacks explicit when-to-use vs sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: fix=true applies defaults to fill missing fields, while fix=false reports only. It also names the default checked fields. But it leaves out details like required permissions, reversibility, and behavior with custom required_fields that lack defaults.
Agents need to know what a tool does to the world before 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 front-loaded with purpose and context, then organized into a clear Args block. Every line earns its place by adding necessary detail for the six parameters, with no filler or redundant repetition of schema types.
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 is present and the description covers purpose, defaults, and fix behavior, this is largely complete. Minor gaps remain around edge-case behavior, such as what happens when fix=true but no default is provided for a custom required field.
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 Args block compensates for the schema's 0% description coverage by explaining each parameter's meaning, default value, and conditional usage based on fix. It adds meaningful semantics beyond the raw schema, such as 'used only if fix=true' and the default field list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Check (and optionally fix) that tasks have required fields set' uses a specific verb and resource, immediately clarifying the tool's role. It distinguishes itself from sibling update_task by focusing on compliance checks and optional batch defaults, not arbitrary edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'Useful for sprint compliance' and explains the default checked fields. However, it does not explicitly state when to prefer this tool over update_task, bulk_update_tasks, or when to avoid using fix mode.
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 and idempotentHint=true. The description adds the behavioral trait 'Cached per session', which is useful and not redundant. This enriches the context beyond the structured 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 two sentences, front-loaded with the primary purpose, and every sentence adds value. No wasted words or redundant details.
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 (zero params, output schema exists), the description is complete. It covers what the tool returns, the caching behavior, and a usage hint, which is sufficient for an agent to invoke 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?
The tool has zero parameters, so the description doesn't need to explain parameter semantics. The baseline for no parameters is 4, and the description adds no irrelevant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current authenticated user's info', listing specific fields (ID, username, email). This distinguishes it from sibling tools like get_my_tasks or get_current_sprint which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for retrieving the authenticated user, with a note to 'Use the ID for assignee operations.' While it doesn't explicitly name alternatives, the context is sufficiently clear for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds value by detailing the return fields (status, assignees, description, subtasks, priority, team label) and noting the include_subtasks default behavior, which goes beyond what the annotations or schema alone convey.
Agents need to know what a tool does to the world before 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 compact and well-structured: a one-line purpose statement, a brief note on accepted ID formats, a sentence on return content, and a clean Args list. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with an output schema, two simple parameters, and no nested objects, the description covers the essential aspects: purpose, input formats, return fields, and default behavior. It lacks an explicit comparison to search_tasks for retrieval workflows, but overall it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining both parameters: task_id specifies the accepted formats (custom ID or UUID) and include_subtasks explains its function and default (true). This adds meaning well beyond the bare type info 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 opens with 'Get detailed info for a task,' a specific verb+resource phrase that clearly differentiates it from sibling tools like search_tasks (searching) or get_sprint_tasks (listing tasks in a sprint). It also lists the kind of information returned (status, assignees, subtasks, priority, etc.), reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that it 'Accepts custom IDs (DEV-1234) or UUIDs,' which implies the tool is used when you have a specific task ID in hand. However, it does not explicitly mention when to prefer this over alternatives like search_tasks or when not to use it, so it lacks explicit exclusion/alternatives 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 readOnlyHint=true, and the description adds value by explaining the return behavior: 'Returns the configured CLICKUP_TEAM_LABELS mapping, or an empty object if not configured.' It also adds the lowercase naming requirement. 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 three sentences, the first sentence states the core purpose, and the subsequent sentences add essential context without waffle. 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?
For a zero-parameter list tool, the description is complete: it names the output, explains the source (CLICKUP_TEAM_LABELS mapping), handles the unconfigured case, and gives practical usage guidance. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so by rubric baseline is 4. The description correctly focuses on output rather than input. No parameter documentation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 available Component/Team labels and their IDs.' This is a specific verb (List) and resource (labels/IDs), and it differentiates from siblings by immediately connecting to task creation/update usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use team names (lowercase) when creating or updating tasks with a team parameter.' This tells the user when the output is needed. It does not explicitly exclude alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, but the description adds crucial context by stating the action is permanent and cannot be undone. It also explains acceptable task_id formats, enhancing transparency beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a brief Args section. Every sentence provides value with no unnecessary verbosity.
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 single-parameter delete tool with an output schema present, the description is complete. It covers the action, irreversibility, and parameter semantics, making it 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 0% schema description coverage, the description fully explains the only parameter (task_id) by specifying it can be a custom ID or ClickUp UUID. This adds significant meaning beyond the schema's minimal 'Task Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specifies a destructive action: 'Delete a task permanently.' It uses a specific verb and resource, and is unambiguously distinct from sibling tools like update_task or get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is for permanently removing a task. It doesn't explicitly mention exclusions or alternatives, but for a delete operation the usage is unambiguous, and the irreversible nature is highlighted.
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, covering the safety profile. The description adds useful behavioral context beyond annotations: 'query' is client-side filtered (important for result expectations), and 'subtasks' default is inverted from search_tasks (documenting a deliberate behavioral difference). It does not contradict 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: a one-sentence purpose, a one-sentence wrapper note, and a tight Args list covering all 8 parameters without fluff. Each line earns its place and the structure aids readability.
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, return values need not be described. The description covers purpose, relation to search_tasks, and every parameter with enough detail. No prerequisites or missing behaviors are apparent for this read-only task query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. The Args section explains every parameter meaningfully: date formats (ISO or Unix millis), 0-indexed page, include_closed default, and the subtasks inversion. This is far beyond what the schema titles alone provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 a specific verb+resource+scope: 'Get tasks assigned to the current user across all lists.' This clearly distinguishes it from siblings like search_tasks (general search) and get_list_tasks (single list). The 'Convenience wrapper around search_tasks' further clarifies its niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names search_tasks as the alternative and explains the difference (automatic user resolution), giving clear context for when to use this tool. However, it does not explicitly state when-not to use it (e.g., 'use search_tasks if you need to specify another user'), so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description does not contradict this. It adds context such as configuration requirements, the behavior of extracting PR links from descriptions and comments, and a latency warning for comment fetching, which 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 concise and front-loaded, starting with the core purpose, followed by return value details, requirements, and parameter explanations. It uses a clear Args section with no unnecessary verbiage.
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 adequately covers purpose, parameters, prerequisites, and performance. It is complete for an agent to select and invoke the tool correctly, even though it doesn't cover error cases in detail.
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?
With 0% schema description coverage, the description fully explains both parameters: 'team' filters by Component/Team label and requires specific config, and 'include_pr_links' controls PR link extraction with a default of true and performance implications. This compensates entirely for the 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?
The description opens with 'Generate a structured sprint status report,' clearly identifying a specific verb and resource. It then details the report's contents (grouped by assignee, status summary, at-risk flags, unassigned task warnings, optional PR links), which distinguishes it from sibling tools like get_sprint_tasks and get_current_sprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the report and its filtering options, but it does not explicitly name alternatives or say when not to use this tool. It does state prerequisites (DEVELOPMENT_SPACE_ID, SPRINTS_FOLDER_ID) and that team filtering requires CLICKUP_TEAM_LABELS, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, lowering the burden. The description adds behavioral detail: it returns hierarchy up to a configurable depth, explains depth semantics (1=folders only, 2=folders+lists, 3=+sublists), and notes the default space. 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 compact and well-structured: a one-line purpose, a sentence about return value and use case, and a clean two-parameter Arg list. Every sentence earns its place with no filler.
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 browse tool with 2 optional parameters and an existing output schema, the description covers the purpose, usage, parameter semantics, and default behavior. It is fully sufficient for an agent to decide when and how to invoke it.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: space_id ('Space to browse. Defaults to the configured DEVELOPMENT_SPACE_ID') and max_depth ('How deep to recurse' with explicit level meanings). This goes beyond the schema's bare type/default 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 uses a specific verb ('Browse') and resource ('workspace folder/list hierarchy'), clearly distinguishing it from sibling tools like get_list_tasks or get_sprint_tasks. It also states the return ('folders and lists') and the main use case (discover list IDs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use: 'Use this to discover list IDs for creating tasks or browsing backlogs.' It also explains default behavior for space_id but does not explicitly mention when not to use or name alternatives, so it's clear but not a full when/when-not guide.
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, so the operation is known to be safe. The description adds valuable context beyond the annotation by clarifying what the tool returns (metadata only) and its limitation regarding comment threads. This gives the agent a fuller behavioral picture without conflicting 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 compact and well-structured: it leads with the main purpose, then provides usage guidance, then a limitation, then parameter detail. Every sentence adds value, with no redundant or filler 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?
For a single-parameter read-only tool, this description is complete. It covers purpose, usage context, limitations, and parameter semantics. The output schema exists, so return values don't need to be spelled out. The available annotations (readOnlyHint, openWorldHint) further round out the 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?
The schema provides no description for doc_id (0% coverage), so the description's 'Args' section is essential. It explains that doc_id is 'The Doc's ID, as returned by create_doc,' giving the parameter context and origin. This meaningfully compensates for the schema gap, though a concrete example of the ID format would have made it even stronger.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Get a Doc's metadata — name, parent location, visibility.' It specifies a concrete verb and resource, and lists the exact fields returned. It also distinguishes itself from get_doc_page/get_doc_pages by explicitly noting those are for page content, providing clear sibling 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 directs users to use get_doc_page or get_doc_pages for reading page content, giving clear alternatives. It also notes a limitation (no Doc-comment endpoint in ClickUp's public API), which helps the agent decide when this tool is not 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?
The description discloses that the tool clears and re-fetches cache, which is behavior beyond the idempotentHint annotation. It doesn't mention any potential side effects like rate limiting or permission requirements, but for a cache refresh tool the description is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences with the key action in the first sentence and usage guidance in the second. No wasted words; perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter cache refresh tool with an output schema, the description covers purpose and usage context sufficiently. It's simple enough that nothing more is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is fully covered. The description doesn't need to add parameter-level details. The baseline of 4 applies because no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Clear and re-fetch the cached sprint info' which clearly distinguishes it from sibling tools like get_current_sprint by focusing on cache refresh. It also names the resource ('cached sprint info') exactly.
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: 'when a sprint rolls over mid-session or if get_current_sprint returns stale data.' This gives clear context and references the alternative get_current_sprint, making the decision straightforward.
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 meaningful behavioral details: auto-resolving the sprint list and current user, fallback behavior when parent_task_id is in a different list, the list_id_override result field, and omission rules for optional parameters. Annotations only provide destructiveHint:false, so this context goes well beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, followed by essential behavioral notes and a well-organized parameter list. Every sentence adds value, and the structure makes it easy to scan.
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 does not need to enumerate return fields. It covers prerequisites, edge-case behavior with parent lists, and points to a specific result field. This is sufficient for correct 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?
The input schema has zero descriptions for all 7 parameters. The description's Args section fully compensates by documenting each parameter, including defaults (assign_to_me), format expectations (parent_task_id), and omission semantics (points/status omitted unless given). This is exactly what the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 creates a task in the current sprint, using a specific verb and resource. The phrase 'with sensible defaults' adds nuance, and the mention of 'current sprint' distinguishes it from sibling tools like create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (creating a task in the current sprint) and lists configuration prerequisites. However, it does not explicitly name alternative tools for non-sprint tasks or state when not to use it, so it stops short of full explicit 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?
It discloses a critical non-obvious behavior: the query parameter is applied client-side after each API page fetch, and has_more reflects API pagination rather than matching-result completeness. This goes well beyond the readOnlyHint and openWorldHint annotations, providing essential operational 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?
The description is efficiently structured: a one-line purpose, a critical note about pagination behavior, and a compact arg list. Every sentence adds value, and the format 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 complex tool with 9 parameters, an output schema, and annotations, the description fully covers usage semantics, behavioral caveats, and pagination. It is complete enough for an agent to use correctly without additional investigation.
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 description coverage is 0%, but the description compensates by explaining each of the 9 parameters in the Args list, including the client-side filtering semantics for query, date format expectations, page indexing, and defaults. This adds significant meaning beyond the bare 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 'Search tasks across the workspace' with a specific verb and resource, and the filtering capabilities distinguish it from sibling tools like get_task or get_list_tasks. It unambiguously identifies this as the general-purpose search/filter tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (for searching tasks across the workspace with filters) and provides usage context, but it does not explicitly exclude alternatives or mention when not to use it. The hint to use get_current_user for assignee_id adds practical 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 annotations (readOnlyHint, idempotentHint) already indicate a safe read operation. The description adds valuable behavior: auto-detection by date, per-session caching (with a stale-data risk), and configuration requirements. This goes beyond what annotations alone convey and is not contradictory.
Agents need to know what a tool does to the world before 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: a single-sentence purpose, followed by a behavior note, and a configuration note. Every sentence carries essential information without unnecessary elaboration. It is immediately scannable 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?
For a simple zero-parameter tool with an output schema, the description covers all necessary aspects: what it returns, how it auto-detects, caching behavior, an alternative tool, and required configuration. The presence of an output schema means return-value details are already structured, so the description is complete without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics (100% coverage). The description correctly focuses on the return value (list ID, name, date range) rather than parameters, which is appropriate for a no-parameter tool. A baseline of 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Get the current sprint's info (list ID, name, date range).' This specifies the action (get), the resource (current sprint), and the exact output fields. It distinguishes itself from sibling tools like get_sprint_tasks (tasks) and refresh_sprint_cache (cache refresh) by focusing on the sprint's metadata.
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 usage context: 'Auto-detected by date' and 'Cached per session — use refresh_sprint_cache if the sprint rolled over.' This tells the agent when the tool is appropriate and when to invoke an alternative (refresh_sprint_cache). It also mentions configuration prerequisites, which are essential for successful 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?
The description discloses behaviors beyond the minimal annotations: it reveals the two sequential API calls with no rollback, the lack of a delete endpoint, and the orphaned Doc risk if the page call fails. It also states the doc is PRIVATE by default and sharing is not handled by this tool. This is rich context that the openWorldHint/destructiveHint annotations do not 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?
Though the description is long, it is tightly structured: purpose + use case, then operational warnings, then an Args list. Every sentence adds value—the failure mode warning, the private default, and the correction path are all essential. There is no fluff or repetition, making it an efficient use of tokens.
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 6 parameters, an output schema (returns URL), and annotations that provide little detail, this description covers all bases: purpose, return value, creation semantics, failure behavior, correction strategy, defaults, and parameter specifics. The agent is fully equipped to decide when to use it, what to pass, and what to expect.
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 0% description coverage, so the description must explain all parameters, and it does. Each parameter is described with default values and nuances (e.g., parent_id defaulting to the configured development space, parent_type needing to match parent_id, content_format options, visibility options). This adds critical meaning beyond the bare schema, especially the warning about mismatched parent_id/parent_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 a specific verb+resource+outcome: 'Create a native ClickUp Doc with one page of content, and return its URL.' This clearly states what the tool does and distinguishes it from sibling tools like update_doc_page and get_doc. The mention of use cases (shareable reports/RFCs) further reinforces the tool's specific role.
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 guidance is given: 'Use this for shareable reports/RFCs that need real markdown tables and headers' and it directly contrasts with task descriptions. It also names an alternative for corrections: 'should use update_doc_page on the existing doc_id/page_id rather than calling create_doc again.' This is exactly the kind of when-to-use vs. when-not-to-use guidance agents need.
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 important non-obvious behaviors beyond the sparse annotations: parent_task_id overrides list_id when they conflict, ClickUp requires parent and child to share a list, and status is omitted unless provided so the target list's default applies. It even mentions the list_id_override field in the result, giving the agent expectations about side effects and output.
Agents need to know what a tool does to the world before 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 a brief intro, a clear preference note, and a compact Args list. Every line provides useful information or rationale, avoiding filler. It is appropriately sized for a 9-parameter tool with several behavioral caveats.
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 9 parameters, 2 required, and an output schema, the description is complete. It covers all parameters, explains inter-parameter behavior, and references the list_id_override result field. The description works with the output schema to give a full picture of the tool's behavior.
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 provides thorough semantics for every parameter: priority mapping, team label lookup, parent_task_id precedence, and the nuanced behavior of status and list_id. This fully compensates for the schema's lack of parameter descriptions and adds meaning far beyond the raw properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Create a new task in a specific list,' a specific verb and resource. It explicitly distinguishes from create_sprint_task, which is a sibling tool, by noting that create_sprint_task auto-resolves the sprint list. This makes the tool's purpose immediately clear and differentiates it from closely related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable. It says to prefer create_sprint_task for sprint tasks, tells users to use get_current_sprint or get_workspace_hierarchy to find list IDs, get_current_user to find assignee ID, and list_teams for team values. This gives clear when-to-use and alternative-tool direction.
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 declare readOnlyHint=true, already signaling a safe read. The description adds valuable behavioral context: sub-pages are flattened into the same list, content is included, and max_page_depth controls nesting levels. These traits go beyond what annotations provide, enriching the agent's understanding.
Agents need to know what a tool does to the world before 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: a clear purpose statement, a usage sentence, a distinction from the singular tool, and a concise Args list. Every sentence adds value without redundancy or excessive length.
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 (multi-page flattening, depth control) and an output schema present, the description covers all essential behavioral aspects: flat list, content inclusion, sub-page handling, and depth default. It is 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?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: doc_id (source of ID), content_format (allowed values and default), and max_page_depth (semantic meaning, default -1). This adds significant meaning beyond the bare 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 begins with a specific verb+resource: 'Get every page of a Doc, content included, as a flat list.' It clearly distinguishes from the sibling tool get_doc_page by explicitly noting 'For a single known page, get_doc_page avoids fetching pages you don't need.' This makes 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?
Provides explicit guidance: 'Use this to read a whole multi-page Doc in one call.' and contrasts with get_doc_page for single-page scenarios. Also explains the flattening behavior for sub-pages, giving clear when-to-use context relative to 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 indicate destructiveHint=true, but the description goes much further: it states the edit happens in place on the existing doc_id/page_id (URL keeps working), that content is always fully replaced, and explains the retry safety rationale for not exposing append/prepend modes. This is rich behavioral context beyond the annotations with 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?
Each paragraph serves a distinct purpose: objective, usage rationale, behavioral caveat, and parameter definitions. The structure is front-loaded with the core action, and every sentence earns its place despite the length. No fluff or 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 (5 params, destructive operation, tricky retry semantics), the description covers behavior, alternatives, parameter meanings, and return value mention. Output schema exists, so not explaining return structure is acceptable. Nothing important 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?
Schema description coverage is 0%, so the description carries full burden. The Args section adds meaning to every parameter: doc_id and page_id are 'as returned by create_doc,' content 'replaces the page in full,' name explains unset keeps existing title, and content_format lists allowed values with default. This fully compensates for the empty 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 opens with a specific verb+resource: 'Overwrite an existing Doc page's content in place, and return its URL.' It also distinguishes itself from the sibling create_doc by explaining the no-delete-endpoint problem, 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?
Explicitly provides when-to-use: 'Use this to correct a previously published Doc ... instead of calling create_doc again.' It also explains why not to use create_doc (orphans the first Doc) and why append/prepend modes are intentionally not exposed (retry safety).
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/asaphe/clickup-mcp/badges/card.svg)](https://glama.ai/mcp/servers/asaphe/clickup-mcp)

Score Badge

Copy to your README.md:

[![clickup-mcp MCP server](https://glama.ai/mcp/servers/asaphe/clickup-mcp/badges/score.svg)](https://glama.ai/mcp/servers/asaphe/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/asaphe/clickup-mcp'

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