Loading ToolBench
A server for managing ClickUp MCP functionalities
The ClickUp MCP server has 6 tools with complete input schemas and consistent descriptions. However, several significant quality issues prevent a higher score: (1) descriptions are generic and lack LLM-optimized guidance on when/why to use each tool; (2) error handling is minimal, exceptions are caught but responses don't guide recovery; (3) the tool descriptions lack actionable context about prerequisites, dependencies, and parameter relationships; (4) output schemas are not formally documented; (5) critical parameter relationships (e.g., team_id required when custom_task_ids=True) are stated but not reinforced with clear warnings. Tool naming is acceptable but generic. The server follows a reasonable structure with proper Pydantic models, but falls short of production-grade documentation expected for A-tier tools.
Create a new task in a list. Parameters: - request: CreateTaskRequest with all task creation parameters Returns: Created task details from ClickUp API.
Delete a task. Parameters: - request: DeleteTaskRequest with task_id, custom_task_ids, and team_id Returns: Success response.
Get a specific task by ID. Parameters: - request: GetTaskRequest with task_id, custom_task_ids, and team_id Returns: Task details from ClickUp API.
Return the current ClickUp user profile using the configured API token. Use this to verify authentication and retrieve your user details (id, email, name).
List tasks in a list with optional filtering. Parameters: - request: ListTasksRequest with list_id, pagination, and filter parameters Returns: List of tasks from ClickUp API.
Error handling returns exceptions as response fields instead of structured errors. E.g., create_task catches exceptions and returns TaskResponse(name=f'Error: {str(e)}'), this conflates success and error responses, forcing LLMs to infer failure from string content. No error classification (retryable, user-fixable, fatal) or recovery guidance.
Tool descriptions lack LLM-optimized guidance on prerequisites and dependencies. E.g., create_task doesn't mention that list_id must be valid, assignees must be existing user IDs, or that calling list_tasks first is often needed to discover valid list_id values. No discovery hints or multi-step workflows documented.
Output schemas are not formally documented in tool descriptions. LLMs cannot know what fields to expect in responses (e.g., TaskResponse structure, which fields are always present, which are nullable). Code defines response models (TaskResponse, UserResponse) but descriptions don't document them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Update an existing task. Parameters: - request: UpdateTaskRequest with task_id and fields to update Returns: Updated task details from ClickUp API.
Critical parameter relationships documented in schema but not reinforced in descriptions. E.g., custom_task_ids=True requires team_id, but the description text for get_task, create_task, update_task, delete_task, list_tasks does not highlight this dependency. LLMs may omit team_id when custom_task_ids is true, causing silent failures.
Destructive operations (delete_task) lack confirmation or dry-run patterns. No suggestion to the LLM that deletion is irreversible or that a confirmation step should precede actual deletion.
Tool descriptions are generic and under-optimized for LLM decision-making. Average description length ~100 chars; baseline for A-tier is 194 chars (p10=34, p90=392). E.g., get_task description repeats parameter names but doesn't clarify WHEN to use it vs list_tasks, or what happens on 404.
get_user catches all exceptions and returns UserResponse with error text in the 'name' field. This silently masks authentication failures, API outages, and permission errors, forcing LLMs to infer failure from string content instead of receiving a clear error response.
No actionable error messages. When an exception occurs, the tool returns a generic string (e.g., 'Error: connection timeout'). LLMs cannot determine if the error is retryable, user-fixable, or fatal. Missing guidance like 'This is retryable, check your API token and try again in 30 seconds.'