Which integrations are available for this server?

Provides tools for managing ClickUp tasks and lists, including retrieving, creating, and updating tasks, with support for task details, assignees, due dates, and statuses.

How do I use ClickUp MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ClickUp MCP Server show me the open tasks from list 987654321" 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.

ClickUp MCP Server

by rubenaguir

Overview Schema Related Servers Score Discussions

JavaScript

Remote

ClickUp MCP Server

A Model Context Protocol (MCP) server that provides integration with the ClickUp API, allowing clients to interact with ClickUp tasks and lists through standardized MCP tools.

Overview

This server implements the MCP protocol to expose ClickUp functionality as tools that can be called by MCP-compatible clients. It supports retrieving, creating, updating, and getting details of tasks in ClickUp lists.

Related MCP server: ClickUp MCP Server

Origin

This MCP server implementation originated from the need to connect KiloCode with ClickUp, enabling seamless integration between the AI-powered code assistant and ClickUp's task management platform.

Features

Task Management: Get, create, and update ClickUp tasks
List Integration: Work with specific ClickUp lists
MCP Compliant: Full MCP protocol implementation using the official SDK
TypeScript: Written in TypeScript for type safety

Installation

Clone or download this repository
Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```

Configuration

Environment Variables

Set the following environment variable before running the server:

CLICKUP_ACCESS_TOKEN: Your ClickUp API access token. You can generate this from your ClickUp account settings under "Apps" > "API Token".

Example:

export CLICKUP_ACCESS_TOKEN=your_clickup_token_here

Usage

Running the Server

After building, run the server:

node build/index.js

The server communicates via stdio (standard input/output), making it suitable for integration with MCP clients.

Client Integration

MCP clients connect to this server and can call the available tools. The server uses JSON-RPC 2.0 protocol for communication.

Client Configuration

To connect an MCP client to this server, configure the client with the server's command and environment variables.

For example, in Claude Desktop, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "clickup": {
      "command": "node",
      "args": ["path/to/clickup-mcp-server/build/index.js"],
      "env": {
        "CLICKUP_ACCESS_TOKEN": "your_clickup_token_here"
      }
    }
  }
}

Replace path/to/clickup-mcp-server with the actual path to this project directory.

Tool: `get_tasks`

Retrieves a list of tasks from a ClickUp list.

Parameters:

list_id (string, required): The ClickUp List ID
limit (number, optional): Number of tasks to retrieve (max 100, default 50)

Example Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_tasks",
    "arguments": {
      "list_id": "987654321",
      "limit": 25
    }
  }
}

Example Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"id\": \"abc123\", \"name\": \"Sample Task\", \"status\": \"open\", \"assignees\": [], \"due_date\": null}, ...]"
      }
    ]
  }
}

Tool: `create_task`

Creates a new task in a ClickUp list.

Parameters:

list_id (string, required): The ClickUp List ID
name (string, required): Task name
description (string, optional): Task description
assignees (array of numbers, optional): Array of assignee user IDs
due_date (string, optional): Due date as Unix timestamp in milliseconds

Example Request:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "create_task",
    "arguments": {
      "list_id": "987654321",
      "name": "New Task",
      "description": "Task description",
      "due_date": "1640995200000"
    }
  }
}

Tool: `update_task`

Updates an existing ClickUp task.

Parameters:

task_id (string, required): The ClickUp Task ID
name (string, optional): New task name
description (string, optional): New task description
status (string, optional): New status
assignees (array of numbers, optional): New array of assignee user IDs
due_date (string, optional): New due date as Unix timestamp in milliseconds

Example Request:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "update_task",
    "arguments": {
      "task_id": "abc123",
      "status": "in progress"
    }
  }
}

Tool: `get_task`

Retrieves details of a specific ClickUp task.

Parameters:

task_id (string, required): The ClickUp Task ID

Example Request:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "get_task",
    "arguments": {
      "task_id": "abc123"
    }
  }
}

Finding ClickUp IDs

List ID: In ClickUp, navigate to your list. The URL will be something like https://app.clickup.com/1234567/v/li/987654321. The number after /li/ is the list ID.
Task ID: Task URLs contain the task ID, or you can get it from the API responses.
User IDs: Use ClickUp's API or interface to find user IDs for assignees.

Error Handling

If an API call fails, the response will include an isError: true field with the error message:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "ClickUp API error: Invalid list ID"
      }
    ],
    "isError": true
  }
}

Testing

A test script is provided to verify that the MCP server is working correctly.

Set your ClickUp access token:

export CLICKUP_ACCESS_TOKEN=your_clickup_token_here

Run the test with a valid list ID:
```
node test-mcp.js <list_id>
```
Replace <list_id> with a valid ClickUp list ID (e.g., 901110500007).

The test will:

Verify that the server initializes correctly
Check that all tools are available
Test the get_tasks tool with the provided list ID

For more comprehensive testing of other tools, you can modify test-mcp.js to include calls to create_task, update_task, and get_task. Note that create_task will create real tasks in ClickUp, so use with caution.

Development

To run in development mode with TypeScript watching:

npm run dev

Dependencies

@modelcontextprotocol/sdk: MCP protocol implementation
axios: HTTP client for ClickUp API
zod: Schema validation
typescript: TypeScript compiler

License

This project is open source. Please check the license file for details.

Available Tools

4 tools

create_taskC

Create a new task in a ClickUp list

ParametersJSON Schema

Name	Required	Description
`list_id`	Yes	ClickUp List ID
`name`	Yes	Task name
`description`	No	Task description
`assignees`	No	Array of assignee user IDs
`due_date`	No	Due date in Unix timestamp (milliseconds)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new task,' implying a write/mutation operation, but fails to disclose critical traits such as required permissions, whether the operation is idempotent, error handling, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('Create a new task') and specifies the context ('in a ClickUp list') without any wasted words. It is appropriately sized for a straightforward tool, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., permissions, side effects), usage guidelines, and what the tool returns. For a create tool with 5 parameters and significant implications, the description should provide more context to aid the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning all parameters are documented in the input schema (e.g., 'list_id' as ClickUp List ID, 'due_date' in Unix timestamp). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Create') and resource ('new task in a ClickUp list'), making the purpose immediately understandable. It distinguishes from siblings like 'get_task' or 'update_task' by specifying creation. However, it doesn't explicitly mention what distinguishes it from other potential creation tools beyond the ClickUp context, keeping it from a perfect score.

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 like 'update_task' or other task management operations. It lacks context about prerequisites (e.g., needing an existing list), exclusions, or typical scenarios for task creation, leaving the agent to infer usage from the name and schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_taskC

Get details of a ClickUp task

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	ClickUp Task ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's likely safe and non-destructive, but doesn't confirm this or address other behaviors like error handling, authentication needs, rate limits, or response format. This leaves significant gaps for a tool that interacts with external 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned (e.g., task fields, status, assignees), error conditions, or how it differs from sibling tools. This leaves the agent with insufficient context to use the tool effectively beyond basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'task_id' documented as 'ClickUp Task ID'. The description doesn't add any meaning beyond this (e.g., format examples, where to find the ID, or validation rules), so it meets the baseline for adequate but unenlightening parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get details') and resource ('ClickUp task'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'get_tasks' (which likely retrieves multiple tasks), leaving some ambiguity about when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage 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 like 'get_tasks' or 'create_task'. It doesn't mention prerequisites (e.g., needing a valid task ID) or contextual factors that might influence tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_tasksC

Get tasks from a ClickUp list

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes	ClickUp List ID
`limit`	No	Number of tasks to retrieve (max 100)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose if this is read-only (implied but not explicit), rate limits, pagination, error handling, or what the return format looks like (e.g., list of tasks). This is inadequate for a tool with parameters and no output schema.

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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., read-only confirmation, return format), usage differentiation from siblings, and any mention of limitations like the max limit of 100. This leaves significant gaps for an agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are documented in the schema. The description adds no additional meaning beyond implying retrieval from a list, which aligns with the schema. Baseline 3 is appropriate as the schema handles parameter documentation effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('tasks from a ClickUp list'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_task' (singular vs. plural) or specify scope (e.g., all tasks vs. filtered), which prevents a perfect score.

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 'get_task' (singular) or 'create_task'. The description implies retrieval but lacks context on prerequisites, such as needing a valid list ID, or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_taskC

Update an existing ClickUp task

ParametersJSON Schema

Name	Required	Description
`task_id`	Yes	ClickUp Task ID
`name`	No	New task name
`description`	No	New task description
`status`	No	New status
`assignees`	No	New array of assignee user IDs
`due_date`	No	New due date in Unix timestamp (milliseconds)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions needed, whether updates are reversible, rate limits, or what happens to unspecified fields, leaving significant gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with zero waste, front-loading the essential action. It's appropriately sized for the tool's purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations, no output schema, and 6 parameters, the description is incomplete. It lacks behavioral context, usage guidelines, and details on return values or error handling, making it inadequate for safe and effective use by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as format details or constraints, but this meets the baseline since the schema handles the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Update') and resource ('existing ClickUp task'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_task' or 'get_task' beyond the basic action, missing explicit comparison.

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 'create_task' for new tasks or 'get_task' for viewing. The description assumes context without explaining prerequisites or appropriate scenarios for updating tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create_task, get_task, get_tasks, and update_task target specific actions on tasks with no overlap. The singular vs. plural distinction between get_task and get_tasks is clear, and create/update are unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case, using clear action verbs (create, get, update) paired with the noun 'task'. There are no deviations in naming conventions.

Tool Count4/5

Four tools are appropriate for a task management server, covering core CRUD operations. It is slightly thin as it lacks delete_task and operations for other ClickUp entities like lists or spaces, but the scope is reasonable for basic task handling.

Completeness4/5

The tool set covers create, read (single and multiple), and update operations for tasks, providing a solid foundation. However, it lacks delete_task and tools for managing other ClickUp resources like lists or comments, which are minor gaps agents might need to work around.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Clickup A
io.github.pipeworx-io
ClickUp MCP — wraps the ClickUp REST API v2 (BYO API key)
Project Management Workplace & Productivity App Automation
362
skr-cloudify-clickup-mcp-server-new
ai.smithery
Manage your ClickUp workspace by creating, updating, and organizing tasks, lists, folders, and tag…
Project Management App Automation Workplace & Productivity
2
Superlist
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2
CalmLoop Task Manager
in.calmloop
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Project Management Note Taking
1

Related MCP Servers

ClickUp MCP Server
Project Management App Automation
windalfin
A
license
A
quality
D
maintenance
A Model Context Protocol server that enables AI agents to interact with ClickUp workspaces, allowing task creation, management, and workspace organization through natural language commands.
Updated a year ago (2025-03-14 04:09 UTC)
21
24,921
2
MIT
ClickUp MCP Server
Project Management Workplace & Productivity App Automation
polaralias
F
license
Not graded
quality
Not graded
maintenance
Enables integration with ClickUp project management platform through a Model Context Protocol server, providing tooling for task management, workspace operations, and team collaboration with flexible authentication and deployment options.
Updated 10 months ago (2025-11-08 20:50 UTC)
252
ClickUp MCP Server
Project Management App Automation Workplace & Productivity
imjoshnewton
A
license
Not graded
quality
D
maintenance
Provides comprehensive tools for AI systems to manage ClickUp tasks, lists, folders, and workspaces through the Model Context Protocol. It enables automated task creation, status updates, subtask management, and custom field manipulation using natural language interfaces.
Updated a year ago (2025-06-30 20:38 UTC)
3
MIT
ClickUp Multi-Workspace MCP
Project Management Workplace & Productivity
alanse-inc
A
license
Not graded
quality
C
maintenance
Enables AI agents to interact with tasks, spaces, lists, and folders across multiple ClickUp workspaces via the Model Context Protocol.
Updated 5 months ago (2026-04-16 07:21 UTC)
60
1
MIT

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

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

ClickUp MCP Server

Overview

Origin

Features

Installation

Configuration

Environment Variables

Usage

Running the Server

Client Integration

Client Configuration

Tool: get_tasks

Tool: create_task

Tool: update_task

Tool: get_task

Finding ClickUp IDs

Error Handling

Testing

Development

Dependencies

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Tool: `get_tasks`

Tool: `create_task`

Tool: `update_task`

Tool: `get_task`