Loading ToolBench
ClickUp MCP Server for AI assistants - Model Context Protocol implementation for ClickUp task management
ClickUp MCP has solid tool naming (verb_noun pattern) and comprehensive parameter schemas with proper types and enums. Descriptions are present and actionable (avg ~120 chars), exceeding the 10-char minimum. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling maps API errors to MCP codes but lacks recovery guidance ('try search_users first'). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Parameter descriptions are adequate but could specify constraints more formally (e.g., 'priority: 1=Urgent, 2=High, 3=Normal, 4=Low' is good; adding 'required' vs 'optional' would help). Missing: idempotency guarantees, batch operations, and natural-identifier support (e.g., accepting task names alongside task_id).
Creates a new task in a specified ClickUp list. Use when users want to add new work items, convert ideas into actionable tasks, schedule future work, or break down projects into manageable pieces.
Retrieves information about the currently authenticated user. Use for personalization and getting user context.
Retrieves lists within a space or folder. Use for discovering task containers and navigation.
Retrieves spaces within a workspace. Use for navigating workspace structure and discovering projects/departments.
Retrieves detailed information about a specific task including metadata, custom fields, and relationships. Use for comprehensive task analysis.
Retrieves tasks from a ClickUp list with filtering capabilities. Use for task overviews, daily summaries, workload analysis, or finding specific tasks.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., does get_tasks return task_id, task_name, or both? Are results paginated?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server.ts marks tools as READ_ONLY or WRITE in comments, but MCP protocol annotations are absent. LLMs cannot infer safety/retry semantics.
Error handling lacks recovery guidance. server.ts maps errors to MCP codes (InvalidRequest, InvalidParams, InternalError) but does not suggest next steps. E.g., 'RESOURCE_NOT_FOUND' should suggest 'Try get_lists() to find valid list_id values.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Retrieves all ClickUp workspaces accessible to the user. Use for workspace discovery and navigation.
Updates an existing task properties. Use for status changes, reassignments, priority updates, or modifying due dates.
No natural-identifier support. Tools require opaque IDs (list_id, task_id, team_id) but users think in names. Agents must call discovery tools first (get_lists, get_spaces) before creating/updating tasks, adding latency and context overhead.
Pagination not documented. get_tasks accepts 'page' parameter but response structure (total_count, next_page, items) is not specified. Large result sets may exceed context window without explicit limits.