Provides tools for managing ClickUp tasks and user profiles, including creating, updating, deleting, and listing tasks, as well as retrieving user information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ClickUp MCP Server Create a task named 'Review PR' in list 12345"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables Claude Desktop to interact with ClickUp through natural language commands.
User Management: Get current user profile and verify authentication
Task Management: Complete CRUD operations - get, create, update, delete tasks
Task Listing: List and filter tasks with pagination
Natural Language: Ask Claude to manage your ClickUp workspace in plain English
Related MCP server: ClickUp MCP Server
Install: python -m pip install -e .
Configure: Add to Claude Desktop config with your CLICKUP_API_TOKEN
Test: Ask Claude "Use the clickup server to get my user profile"
Create: "Create a task named 'Test Task' in list LIST_ID"
Python 3.10 or higher
ClickUp API token (get one here)
Clone the repository:
git clone https://github.com/deniskrds/clickup-mcp-server.git
cd clickup-mcp-serverCreate a virtual environment:
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activateInstall the package:
python -m pip install -e .Create environment file:
cp .env.example .env
# Edit .env and add your CLICKUP_API_TOKENOpen Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the MCP server configuration:
{
"mcpServers": {
"clickup": {
"command": "clickup-mcp",
"env": {
"CLICKUP_API_TOKEN": "your_token_here"
}
}
}
}Restart Claude Desktop
Once configured, you can ask Claude to manage your ClickUp workspace:
"Use the clickup server to get my user profile"
"Verify my ClickUp authentication"
"Use the clickup server to create a task named 'Review PR' in list LIST_ID"
"Update task TASK_ID: set status to 'In Progress'"
"List tasks in list LIST_ID with status 'Open'"
"Get task TASK_ID details"
"Delete task TASK_ID"
Create task: "Use the clickup server to create a task named 'Review PR #456' in list LIST_ID"
Get task details: "Get task TASK_ID to see the created task"
Update task: "Update task TASK_ID: set status to 'In Progress' and assign to user 123"
Complete task: "Update task TASK_ID: set status to 'Complete'"
Tool | Description | Parameters |
| Get current user profile | None |
| Get specific task details |
|
| Create new task |
|
| Update existing task |
|
| Delete a task |
|
| List tasks in a list |
|
The server uses environment variables for configuration:
# Required
CLICKUP_API_TOKEN=your_clickup_token
# Optional (defaults shown)
CLICKUP_APP_ENV=development
CLICKUP_BASE_URL=https://api.clickup.com/api/v2
CLICKUP_REQUEST_TIMEOUT_SECONDS=15
CLICKUP_MAX_RETRIES=2
CLICKUP_RETRY_BACKOFF_SECONDS=0.5clickup_mcp/
├── clickup/ # ClickUp API client
├── tools/ # Task management tools
├── models.py # Pydantic models
├── config.py # Configuration management
└── mcp_server.py # MCP server entry point
tests/
└── test_mcp_server.py # Unit testsImplement helper functions in clickup_mcp/tools/
Register tools in clickup_mcp/mcp_server.py
Add clear docstrings and parameter types
"Server disconnected" error:
Ensure clickup-mcp command is in your PATH
Check that CLICKUP_API_TOKEN is set correctly
Verify Python version is 3.10+
"Module not found" errors:
Reinstall the package: python -m pip install -e .
Activate your virtual environment
Claude can't find the server:
Use absolute path in Claude config: /full/path/to/venv/bin/clickup-mcp
Restart Claude Desktop after config changes
This project is licensed under the MIT License. See the LICENSE file for details.
Contributions are welcome! Please open an issue or submit a pull request.
For questions or support, please open an issue on GitHub.
Create a new task in a list.
Parameters:
request: CreateTaskRequest with all task creation parameters Returns: Created task details from ClickUp API.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | Task ID |
| name | Yes | Task name |
| description | No | Task description |
| status | No | Task status |
| priority | No | Task priority |
| assignees | No | Task assignees |
| tags | No | Task tags |
| due_date | No | Due date as Unix timestamp |
| created_at | No | Creation timestamp |
| updated_at | No | Last update timestamp |
| url | No | Task URL |
| list_id | No | Parent list ID |
| space_id | No | Parent space ID |
| folder_id | No | Parent folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions returns but does not address side effects, authorization needs, rate limits, or error handling. The description is minimal and lacks important details for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a vague second paragraph about parameters that adds little value. It is not overly verbose but could be rephrased to be more direct while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (not fully shown), the description omits error conditions, authentication requirements, or typical usage scenarios. For a task creation tool, more context is needed to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description does not explain any parameter beyond referencing the nested type name 'CreateTaskRequest'. It fails to add meaningful context about individual parameters such as list_id, name, or assignees, leaving the agent to interpret the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new task in a list.' This clearly indicates the verb (create), resource (task), and context (in a list). It distinguishes itself from sibling tools like delete_task, get_task, update_task, and list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there any prerequisites or exclusions mentioned. The description simply states what it does without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task.
Parameters:
request: DeleteTaskRequest with task_id, custom_task_ids, and team_id Returns: Success response.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| success | No | Operation success status |
| message | No | Success message |
| data | No | Additional data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose irreversible nature, permissions required, or side effects beyond 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinct description in bullet points, no unnecessary words. Could benefit from slightly more structure (e.g., separating behavior from params).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, description omits deletion behavior (e.g., permanent, cascading effects). Incomplete for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description merely lists parameter names without adding meaning or context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a task', a specific verb+resource, and distinguishes from sibling tools (create, get, list, update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives (e.g., update_task). No prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific task by ID.
Parameters:
request: GetTaskRequest with task_id, custom_task_ids, and team_id Returns: Task details from ClickUp API.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | Task ID |
| name | Yes | Task name |
| description | No | Task description |
| status | No | Task status |
| priority | No | Task priority |
| assignees | No | Task assignees |
| tags | No | Task tags |
| due_date | No | Due date as Unix timestamp |
| created_at | No | Creation timestamp |
| updated_at | No | Last update timestamp |
| url | No | Task URL |
| list_id | No | Parent list ID |
| space_id | No | Parent space ID |
| folder_id | No | Parent folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states 'Returns: Task details from ClickUp API', missing important aspects like auth requirements, rate limits, and that this is a read-only operation. Does not mention error handling or response structure beyond vague 'details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and conveys the basic purpose, but lacks structure. It could benefit from clearly labeling sections like 'Parameters' and 'Returns' instead of inline text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail returns, but it still provides a vague mention. It omits important context such as the dependency between custom_task_ids and team_id, and does not explain potential error scenarios. Adequate for a simple retrieval tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely lists parameter names from the schema ('task_id, custom_task_ids, and team_id') without adding meaning. The schema already provides descriptions for these sub-parameters, so the tool description adds no additional value. With 0% schema description coverage at top-level, the description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific task by ID', which is a specific verb-resource pair. It implicitly distinguishes from siblings like list_tasks (retrieves multiple) and update_task (modifies), but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_tasks for multiple tasks). No mention of prerequisites or contextual conditions like requiring team_id when custom_task_ids is true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current ClickUp user profile using the configured API token.
Use this to verify authentication and retrieve your user details (id, email, name).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| id | Yes | User ID |
| Yes | User email | |
| name | No | User name |
| username | No | Username |
| initials | No | User initials |
| profile_picture | No | Profile picture URL |
| color | No | User color |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly indicates read operation with no side effects, and mentions returned fields (id, email, name). Could mention rate limits but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not shown; description partially covers returns (id, email, name). For zero-param tool, description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%. Baseline for 0 params is 4. Description adds no parameter info but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return the current ClickUp user profile' with specific verb and resource. Siblings are all task-related, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to verify authentication and retrieve your user details', providing clear context. No need for exclusions given sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| tasks | Yes | List of tasks |
| total_count | No | Total number of tasks |
| page | Yes | Current page number |
| limit | Yes | Number of tasks per page |
| has_more | No | Whether there are more tasks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states it returns a list of tasks, but does not disclose pagination behavior (e.g., that it returns one page at a time) or other side effects. The output schema partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with one sentence stating purpose and a bullet list for parameters/returns. However, the parameter list is redundant with the schema, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to mention pagination details (page, limit) that are critical for using this tool correctly. It also omits authentication or rate limit info. However, output schema adds some completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add significant meaning beyond the input schema, which already describes each parameter (e.g., list_id, pagination, status filter). Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List tasks in a list with optional filtering', using a specific verb ('list') and resource ('tasks in a list'). It distinguishes from sibling tools like create_task, delete_task, and get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing tasks with filtering, but lacks explicit guidance on when to use this tool vs alternatives (e.g., get_task for a single task). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task.
Parameters:
request: UpdateTaskRequest with task_id and fields to update Returns: Updated task details from ClickUp API.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | Task ID |
| name | Yes | Task name |
| description | No | Task description |
| status | No | Task status |
| priority | No | Task priority |
| assignees | No | Task assignees |
| tags | No | Task tags |
| due_date | No | Due date as Unix timestamp |
| created_at | No | Creation timestamp |
| updated_at | No | Last update timestamp |
| url | No | Task URL |
| list_id | No | Parent list ID |
| space_id | No | Parent space ID |
| folder_id | No | Parent folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Update an existing task' and 'Returns updated task details.' No annotations exist to carry behavioral context, so the description must disclose side effects, authentication needs, or rate limits. It fails to do so, offering minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three sentences plus a parameter line) and front-loaded with purpose. It includes a structured 'Parameters:' and 'Returns:' section, making it easy to scan. No excess text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (nested request object) and no annotations, the description should clarify that the task must exist, mention which fields are updatable, and describe the return format. It only gives a vague 'Updated task details' and omits error conditions or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'request: UpdateTaskRequest with task_id and fields to update,' adding context beyond the schema name. However, the schema already describes fields individually. Since there is only one parameter and the description adds little new detail, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing task,' explicitly naming the verb (update) and resource (task). This distinguishes it from sibling tools like create_task, delete_task, and get_task, providing unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., create_task for new tasks, delete_task for removal). No preconditions or usage context are mentioned, 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.
Each tool has a distinct purpose: creating, deleting, getting, listing, and updating tasks, plus retrieving user info. No overlapping functionality.
All tools follow a consistent verb_noun pattern (e.g., create_task, get_task, list_tasks), making them predictable and easy to understand.
With 6 tools, the server covers essential task operations (CRUD) plus user verification, which is a reasonable scope for a task-focused MCP server.
The tool set provides full CRUD for tasks and user authentication, which covers basic task management. Minor gaps exist, such as no tool for managing lists or members, but core functionality is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Your Aurentia workspace — projects, CRM, tasks, deliverables — in Claude, Cursor or any MCP client.
Manage your ClickUp workspace by creating, updating, and organizing tasks, lists, folders, and tag…
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deniskrds/clickup-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server