Public API

Firts of all love the official Clickup MCP server. Our SDLC workflow has been trasnformed with it. One issue we seeing is it uses 34K tokens and that's roughly 17% of claude's 200K context window. Any optimisation that can be done ? Screenshot is from Claude code's "/context" command.

The ClickUp API has no mechanism to suppress notifications when updating tasks. Every API call to PUT /task/{task_id} or POST /task/{task_id}/field/{field_id} generates a notification to all task watchers. There is no query parameter, header, or flag to prevent this. Why this is critical: Any organization automating workflows via the ClickUp API at scale hits this wall. Our example: we manage 200+ projects in Professional Services. A daily n8n automation propagates metadata (Customer Name, Project Code, Region, etc.) from a master task to hundreds of sibling tasks. Every field write notifies every watcher, creating a flood of irrelevant notifications that bury relevant updates.

I want to add fields that I can update with the API, like Email, ratings, etc.

Ship an official ClickUp CLI as a deterministic alternative to MCP for agent workflows Problem We are building AI-driven workflows where agents run locally or in CI and need a tool surface that is: deterministic and cheap at runtime self-describing (so agents do not guess capabilities) stable across time (versioned contracts) MCP introduces overhead and token cost due to tool discovery and repeated schema/context exchange. We want a CLI-first interface that is always up to date and can be invoked by agents and automation systems. Request Please ship an official ClickUp CLI that wraps core ClickUp APIs and Automation Webhooks, with the following requirements: Help-first, machine-readable contracts clickup --help and clickup <cmd> --help must be complete and structured include input flags, examples, output schemas, and exit codes JSON by default All commands output strict JSON by default (--human optional) Stable schemas with versioning Stable exit codes 0 success 2 needs_input/validation error 3 blocked/permission/auth/rate limit 4 failed/unexpected Authentication OAuth device flow (ideal), plus optional support for personal tokens for power users Clear scoping to a workspace Core commands (v1) tasks get|search|create|update comments create|list lists get|search webhooks create|test (or automation webhook helpers) docs get|search (if feasible) Safety controls --dry-run to show mutations without applying explicit confirmation flag for destructive operations Auto-update / version pinning ability to force update before run (agent-friendly) ability to pin versions for CI reproducibility Why this matters This enables a “ClickUp as coordination layer” architecture where: ClickUp is the UI + state machine external agents/CLIs do deterministic work in codebases updates are written back to ClickUp reliably This is lower cost and higher control than MCP-style tool calling for many teams. Related Automation webhooks already exist and work well; a CLI would complement them as the execution surface.

When creating or updating tasks via the API using markdown_description, extra vertical spacing (empty line) is added between different block types: heading to text, text to heading, text to bullet list, and bullet list to text. Consecutive bullet points and consecutive text lines render correctly without extra spacing. The same content typed manually in the editor does not produce this extra spacing. Confirmed with both direct REST API calls and the MCP connector, same behavior. It would be useful to either fix this so the API renders the same as the editor, or provide an option/parameter to control paragraph spacing in markdown_description (e.g. a compact_markdown flag or similar).

Both clickup_get_time_entries and clickup_get_task_time_entries are broken due to a tags field type mismatch in the output schema. Root Cause: The ClickUp API returns tags as an array of objects ( [{name, tag_fg, tag_bg, ...}] ), but the MCP output schema defines it as string[] . This fails structured content validation. Symptoms: get_time_entries : Throws MCP error -32602 with "expected": "string", "received": "object" for every entry. In our test, the API successfully returned 206 entries but all were rejected by validation. get_task_time_entries : Silently returns empty results ( {"timeEntries": [], "total": 0} ) on tasks that have confirmed tracked time via get_task ( time_spent > 0 ). Verified across multiple tasks. Fix: Update the output schema for both tools to define tags as an array of objects. Note: These tools were working via Claude.ai in mid-March 2026. This may also explain Gretchen Elliott's March 17 report in this thread — get_time_entries does exist as an MCP tool but is currently unusable.

Description: I am experiencing an issue where tasks located within archived lists are not being returned by the API, even when I provide the specific list_id. I have tested the following endpoints: GET https://api.clickup.com/api/v2/list/{list_id}/task GET https://api.clickup.com/api/v2/team/{team_id}/task Current Behavior: When a List is archived, the tasks within it seem to become "invisible" to these endpoints. If I provide a direct list_id for an archived list, the response returns an empty array or an error, rather than the tasks contained within that list. Expected Behavior: If a developer provides a specific list_id, the API should return the tasks belonging to that list regardless of whether the list is archived or not, or at least provide a parameter to include archived content. Questions: Is this an intended limitation or a bug? Is there a specific query parameter (like include_archived=true) that I should use to retrieve tasks from archived containers? If these endpoints do not support archived lists, what is the recommended way to fetch all tasks (active and archived) for a specific Workspace/Team?

Sometimes the only thing I need from an API token is to read a few things. Especially if the token is going into a shared environment of some kind - Having a read-only / no-op token is important.

The Open API docs are a mess, and the response on runtime does not match the models. For example: "Getting Tasks of a List" ( https://clickup.com/api/clickupreference/operation/GetTasks/ ) I receive custom_fields of each task with the values on runtime, but it is not specified by the API documentation. Also, what I get is the model "Task9", that differs to the models Task, Task1, Task2, Task3, Task4, Task5, and Task6. Yes, there are seven different models defined for a task.

Using the API GET TASKS to search for Tasks with specific words in the Title, and also in the description as a bonus.