ClickUp MCP Server (first-party and official)
building now
Jordan Cleigh
Model Context Protocol (MCP) is basically a must-have feature for all SaaS now. ClickUp providing an official, first-party server would allow users to interact with ClickUp API directly through their agentic AI tool of choice (Claude, GitHub Copilot, Cursor, etc.)
Most of ClickUp's competitors already offer their own first-party, official MCP server. ClickUp is falling behind in this space, unless it is just not announced yet.
Several people have created unofficial ClickUp MCP servers, but they are never going to be as good as what a first-party server could provide.
Note: This is not related to MCP support in ClickUp AI (https://feedback.clickup.com/feature-requests/p/support-mcp-model-context-protocol-in-clickup-ai), which is requesting support for other provider's servers in ClickUp.
Log In
E
Erra Faye Zabat
building now
Hey, everyone! We’re excited to share that we’ve created new statuses in Canny to provide more transparency and clarity around the progress of feature requests. We've updated the status of this request to reflect the updated status. The Product Manager will provide updates on this post when they have new details to share!
B
Brian McSweeney
Plus one for this feature
Jordan Cleigh
Hi Tadej!
We're currently using an internal fork of an unofficial ClickUp MCP Server integrated primarily with GitHub Copilot. The primary workflow/problem this solves is not having to duplicate content between ClickUp and GitHub. Instead, I can tell Copilot agent to "Fetch the ClickUp task with custom ID ABC-123 and do the work described" and it works very well. We can also use tools like updating the status of a task, updating the description, posting comments, and similar flows. Essentially, we're working on providing Copilot all the context and tools it needs to operate like one of our human developers.
We are also using GitHub MCP and Playwright MCP regularly. GitHub provides the tools for the agents to open and update pull requests and fetch repositories. Playwright provides the agent a way to interact with the browser DOM for automated testing and UI validation.
These are all primarily used within VS Code, JetBrains IDEs, and github.com. We will also use in Visual Studio when supported.
I think the minimum tooling would be:
- Fetch tasks by ID and custom ID
- Fetch lists
- Search tasks in a list (I think this is required for custom task IDs)
- Post comments
- Update task status
- Update task description
I removed all the destructive actions from custom fork I spun up as I don't want the agent accidentally deleting tasks, lists, etc. I don't know if that is serviceable for the larger customer base, but something to consider.
Authentication is API key based and should then look like the user is doing these actions even if the LLM agent is performing the action using a tool on the user's behalf.
Another note is that the first wave of MCP servers were largely container-based, but the more recent trend is remote HTTP-based, meaning ClickUp runs the MCP server as a hosted application and our LLM agents interact with it like we would with the API.
Let me know if you are interested in a call or demo of what we're doing today, I'd be happy to share!
Tadej Jevševar
considering
Tadej Jevševar
Hey Jordan!
Really appreciate you raising this request for an official ClickUp MCP Server. We’re seriously exploring how to support AI agent workflows, and MCP is one of the most promising directions we’re looking at.
To better understand how we can build something truly useful, I’d love to learn more about your workflows:
- What problem would a ClickUp MCP Server solve for you specifically?
- What MCP clients/IDEs are you using today to run MCP Servers (e.g. Cursor, VC Code, Claude, etc.)?
- Are you already using other MCP servers? If so, which ones and what do you like about them?
- What tools should a ClickUp MCP Server absolutely support? (e.g. create task, post comments, search tasks, etc.)
Your answers will help us shape the right experience and prioritize the tools that matter most.
S
Shreyansh Jain
Tadej Jevševar Please let Claude access Clickup's data and also do make sure that relationships between tasks are given properly.
I have a very relationship heavy workspace majorly using custom fields. And letting Claude make complete sense of those is a must for us.
We'll be using claude to tidy up our databases, manage them with external knowledge bases.
Jordan Cleigh
Tadej Jevševar
(reposting from above as I just realized I did not do this as a reply)
Hi Tadej!
We're currently using an internal fork of an unofficial ClickUp MCP Server integrated primarily with GitHub Copilot. The primary workflow/problem this solves is not having to duplicate content between ClickUp and GitHub. Instead, I can tell Copilot agent to "Fetch the ClickUp task with custom ID ABC-123 and do the work described" and it works very well. We can also use tools like updating the status of a task, updating the description, posting comments, and similar flows. Essentially, we're working on providing Copilot all the context and tools it needs to operate like one of our human developers.
We are also using GitHub MCP and Playwright MCP regularly. GitHub provides the tools for the agents to open and update pull requests and fetch repositories. Playwright provides the agent a way to interact with the browser DOM for automated testing and UI validation.
These are all primarily used within VS Code, JetBrains IDEs, and github.com. We will also use in Visual Studio when supported.
I think the minimum tooling would be:
- Fetch tasks by ID and custom ID
- Fetch lists
- Search tasks in a list (I think this is required for custom task IDs)
- Post comments
- Update task status
- Update task description
I removed all the destructive actions from custom fork I spun up as I don't want the agent accidentally deleting tasks, lists, etc. I don't know if that is serviceable for the larger customer base, but something to consider.
Authentication is API key based and should then look like the user is doing these actions even if the LLM agent is performing the action using a tool on the user's behalf.
Another note is that the first wave of MCP servers were largely container-based, but the more recent trend is remote HTTP-based, meaning ClickUp runs the MCP server as a hosted application and our LLM agents interact with it like we would with the API.
Let me know if you are interested in a call or demo of what we're doing today, I'd be happy to share!
New edit: Another use case we have explored is to use a LLM client (Claude, Copilot, etc), to create tasks. I have pushed for using ClickUp AI instead, but this is still a valid use case.