Which integrations are available for this server?

Provides tools for interacting with ClickUp's API, including listing and updating tasks, and managing docs and wikis (list, create, edit).

How do I use clickup-custom-mcp?

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-custom-mcp List tasks in the 'Sprint Backlog' list." 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-custom-mcp

by lucaspsantana

Overview Schema Related Servers Score Discussions

JavaScript

Remote

clickup-custom-mcp

Servidor MCP (Model Context Protocol) customizado para integrar o ClickUp com assistentes de IA em qualquer projeto — sem copiar configuração para cada repositório.

Diferente do MCP oficial do ClickUp (https://mcp.clickup.com/mcp, OAuth), este servidor usa a API REST do ClickUp com Personal Access Token e expõe ferramentas focadas em tasks e docs/wikis.

Início rápido

git clone git@github.com:lucaspsantana/clickup-mcp-server.git ~/mcp-servers/clickup-mcp-server
cd ~/mcp-servers/clickup-mcp-server
npm install
cp .env.example .env   # edite com suas credenciais
npm run setup

Reinicie os IDEs configurados. Pronto — funciona em todos os seus projetos.

Sem .env? Rode npm run setup e o script pergunta API Key e Team ID interativamente.

Related MCP server: clickup-mcp

Credenciais

Você precisa de duas informações do ClickUp:

Variável	Onde obter
`CLICKUP_API_KEY`	Settings → Apps → API Token
`CLICKUP_TEAM_ID`	Número na URL: `https://app.clickup.com/{team_id}/...`

Onde colocar (em ordem de prioridade)

O script npm run setup busca credenciais nesta ordem:

Argumentos CLI — --api-key / --team-id
Arquivo .env na raiz do repo (recomendado)
Variáveis de ambiente — CLICKUP_API_KEY / CLICKUP_TEAM_ID
Prompt interativo — se nada acima existir

`.env` (recomendado)

cp .env.example .env

CLICKUP_API_KEY=pk_xxxxxxxx
CLICKUP_TEAM_ID=12345678

O .env é ignorado pelo Git. O setup grava as credenciais nos arquivos MCP dos IDEs — você configura uma vez.

Variáveis de ambiente do sistema

Alternativa ao .env — adicione ao ~/.bashrc ou ~/.zshrc:

export CLICKUP_API_KEY="pk_xxxxxxxx"
export CLICKUP_TEAM_ID="12345678"

IDEs abertos pelo menu do SO podem não herdar o .bashrc. Se isso acontecer, use .env + npm run setup (grava direto no JSON do IDE).

O que o `npm run setup` faz

Credenciais — lê .env, env vars, ou pergunta interativamente
IDEs — auto-detecta instalados (Cursor, VS Code, Claude, Kiro, Trae, Windsurf…)
Binário — roda npm link se clickup-custom-mcp não estiver no PATH
Config global — grava nos arquivos MCP de cada IDE
Backup — salva .bak.<timestamp> antes de sobrescrever
Preserva — mantém outros servidores MCP já configurados

Opções do script

npm run setup                                          # interativo
npm run setup -- --yes                                 # sem prompts (exige .env)
npm run setup -- --ides cursor,vscode                  # IDEs específicos
npm run setup -- --all-ides                            # todos (ignora auto-detecção)
npm run setup -- --include-official                    # + MCP oficial ClickUp (OAuth)
npm run setup -- --dry-run                             # simula sem escrever
npm run setup -- --api-key pk_xxx --team-id 12345678   # credenciais na CLI
clickup-mcp-setup --help                               # ajuda completa

Arquivos que o script escreve

IDE	Arquivo global (Linux)	Chave JSON
Cursor	`~/.cursor/mcp.json`	`mcpServers`
Claude Code	`~/.claude.json`	`mcpServers`
Claude Desktop	`~/.config/Claude/claude_desktop_config.json`	`mcpServers`
VS Code	`~/.config/Code/User/mcp.json`	`servers` ⚠️
Kiro	`~/.kiro/settings/mcp.json`	`mcpServers`
Trae	`~/.config/Trae/User/mcp.json`	`mcpServers`
Windsurf	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`

macOS: Claude Desktop → ~/Library/Application Support/Claude/claude_desktop_config.json · VS Code → ~/Library/Application Support/Code/User/mcp.json · Trae → ~/Library/Application Support/Trae/User/mcp.json

Windows: %APPDATA%\Claude\, %APPDATA%\Code\User\, %APPDATA%\Trae\User\

Auto-detecção de IDEs

O script verifica pastas/configs existentes. Se nenhum IDE for detectado, configura Cursor por padrão.

No modo interativo, confirma a lista detectada. Digite all para configurar todos os IDEs suportados.

Ferramentas disponíveis

Ferramenta	Descrição
`clickup_list_tasks`	Lista tasks por list, status, assignee ou busca
`clickup_update_task`	Atualiza status, nome, descrição ou assignees
`clickup_list_docs`	Busca Docs e Wikis no workspace
`clickup_list_doc_pages`	Lista páginas de um Doc/Wiki
`clickup_create_doc`	Cria um Doc
`clickup_edit_doc`	Edita conteúdo de um Doc
`clickup_create_wiki`	Cria um Wiki
`clickup_edit_wiki`	Edita conteúdo de um Wiki

clickup (oficial) vs clickup-custom

Você pode usar os dois simultaneamente:

npm run setup -- --include-official

	clickup (oficial)	clickup-custom (este repo)
Conexão	HTTP remoto (`mcp.clickup.com`)	Processo local (stdio)
Auth	OAuth / login ClickUp	Personal Access Token
Tools	Conjunto oficial ClickUp	Tasks + Docs/Wikis customizados

Configuração manual (alternativa)

Se preferir não usar o script, registre o binário e edite os arquivos manualmente.

1. Registrar binário

npm install
npm link
which clickup-custom-mcp

2. Bloco de configuração

Maioria dos IDEs (mcpServers):

"clickup-custom": {
  "command": "clickup-custom-mcp",
  "env": {
    "CLICKUP_API_KEY": "pk_xxxxxxxx",
    "CLICKUP_TEAM_ID": "12345678"
  }
}

VS Code (servers + type):

"clickup-custom": {
  "type": "stdio",
  "command": "clickup-custom-mcp",
  "env": {
    "CLICKUP_API_KEY": "pk_xxxxxxxx",
    "CLICKUP_TEAM_ID": "12345678"
  }
}

Kiro (não herda PATH — use caminho absoluto):

"clickup-custom": {
  "command": "/caminho/absoluto/clickup-custom-mcp",
  "env": {
    "PATH": "/caminho/do/node/bin:/usr/local/bin:/usr/bin:/bin",
    "CLICKUP_API_KEY": "pk_xxxxxxxx",
    "CLICKUP_TEAM_ID": "12345678"
  },
  "disabled": false
}

Config por IDE

Ferramenta	Global	Por projeto
Cursor	`~/.cursor/mcp.json`	`.cursor/mcp.json`
Claude Code	`~/.claude.json`	`.mcp.json`
Claude Desktop	ver tabela acima	—
VS Code	MCP: Open User Configuration	`.vscode/mcp.json`
Kiro	`~/.kiro/settings/mcp.json`	`.kiro/settings/mcp.json`
Trae	`~/.config/Trae/User/mcp.json`	`.trae/mcp.json` (beta)
Windsurf	`~/.codeium/windsurf/mcp_config.json`	—

Claude Code via CLI:

claude mcp add --scope user clickup-custom -- clickup-custom-mcp

Atualizar

cd ~/mcp-servers/clickup-mcp-server
git pull && npm install

O npm link não precisa ser refeito — o symlink aponta para o repo e o binário é atualizado automaticamente.

Para reconfigurar credenciais ou IDEs:

npm run setup

Solução de problemas

Setup falhou com "Credenciais ausentes"

Crie .env a partir de .env.example ou rode sem --yes para o modo interativo.

Servidor não aparece no IDE

Reinicie o IDE (a maioria só lê MCP na inicialização)
Valide JSON em jsonlint.com
Confirme o binário: which clickup-custom-mcp
Rebuild: npm run build

Erro `CLICKUP_API_KEY is required`

Credenciais não chegaram ao processo MCP. Rode npm run setup novamente — ele grava env direto no JSON do IDE.

Erro 401 / 403 da API ClickUp

Token inválido ou revogado
Token sem permissão no workspace
CLICKUP_TEAM_ID incorreto

VS Code: config do Cursor não funciona

VS Code usa "servers" (não "mcpServers") e exige "type": "stdio". Use npm run setup ou adapte manualmente.

Kiro: binário não encontrado

Kiro não herda PATH. O script já usa caminho absoluto automaticamente. Confirme com which clickup-custom-mcp.

WSL2

Use caminhos Linux (/home/...) quando IDE e MCP rodam no WSL
Se o IDE roda no Windows e o MCP no WSL, instale Node no Windows ou use caminho WSL compatível

Teste manual do servidor

export CLICKUP_API_KEY="pk_xxx"
export CLICKUP_TEAM_ID="12345678"
clickup-custom-mcp

Erro de variável ausente = servidor OK, aguardando stdin MCP. Ctrl+C para sair.

Estrutura do projeto

clickup-mcp-server/
├── src/
│   ├── index.ts              # entrypoint MCP (stdio)
│   ├── client.ts             # axios + env CLICKUP_*
│   └── tools/
│       ├── tasks.ts          # list/update tasks
│       └── docs.ts           # docs e wikis
├── scripts/
│   └── setup-global.mjs      # npm run setup
├── dist/                     # gerado por npm run build
├── .env.example              # template de credenciais
├── package.json
└── tsconfig.json

Scripts

Comando	Descrição
`npm install`	Dependências + build automático (`prepare`)
`npm run setup`	Setup global interativo (recomendado)
`npm run build`	Compila TypeScript → `dist/`
`npm link`	Registra `clickup-custom-mcp` no PATH
`npm start`	Inicia servidor (stdio)
`clickup-custom-mcp`	Binário MCP (após `npm link`)
`clickup-mcp-setup`	Alias do setup (após `npm link`)

Segurança

Nunca commite .env ou tokens no Git (.env já está no .gitignore)
O setup grava credenciais nos configs locais dos IDEs — tratá-los como secrets
Revogue tokens comprometidos em ClickUp Settings → Apps
O token tem o mesmo acesso que sua conta ClickUp — trate como senha

Pré-requisitos

Node.js 18+ (node --version)
Personal Access Token do ClickUp
Team ID (Workspace ID)

Available Tools

8 tools

clickup_create_docB

Create a ClickUp Doc. Optionally attach to a Space, Folder, or List via parent_id.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Doc title
`content`	No	Markdown content for the first page
`parent_id`	No	Parent Space/Folder/List ID
`parent_type`	No		workspace
`visibility`	No		PRIVATE

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as authentication requirements, side effects, or error handling for invalid parent_id. For a creation tool, more transparency is expected.

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 sentence, front-loaded with purpose, and contains no redundant words. Highly concise.

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 no output schema and 5 parameters, the description lacks details on return value (e.g., doc ID), constraints, or error scenarios. Incomplete for a creation tool.

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 60%, and the description adds minimal extra meaning beyond the schema (e.g., 'Optionally attach' hints at parent_id). It does not significantly compensate for the parameters not described in schema.

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

Purpose5/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 the resource 'ClickUp Doc', and mentions optional attachment to Space/Folder/List, distinguishing it from siblings like clickup_create_wiki or clickup_edit_doc.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating docs, but does not specify when to use this vs alternatives (e.g., edit) or provide context on choosing parent types. No explicit when/when-not guidance.

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

clickup_create_wikiB

Create a ClickUp Wiki attached to a Space.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Wiki title
`space_id`	Yes	Space ID where the wiki lives
`content`	No	Markdown content for the first page
`visibility`	No		PUBLIC

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and description does not disclose behavioral traits such as authentication needs, rate limits, or consequences of creating a wiki (e.g., whether it replaces existing wiki).

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?

Single sentence, front-loaded with purpose, no unnecessary words.

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?

Minimal description lacks information on return values, behavior of optional parameters (content, visibility), and overall tool behavior, which is insufficient given no output schema and moderate complexity.

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 already describes all parameters (75% coverage), and description adds no extra meaning beyond the schema; baseline score of 3 is appropriate.

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

Purpose5/5

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

Description clearly states the tool creates a ClickUp Wiki attached to a Space, with a specific verb and resource, distinguishing it from siblings like clickup_create_doc.

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 on when to use this tool vs alternatives like clickup_create_doc, no context or exclusions provided.

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

clickup_edit_docC

Edit a page inside a ClickUp Doc. Updates page name and/or markdown content.

ParametersJSON Schema

Name	Required	Default
`doc_id`	Yes
`page_id`	Yes
`name`	No
`content`	No
`content_edit_mode`	No	replace

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided; description only says 'updates' without disclosing side effects, authentication needs, or behavior of content_edit_mode.

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

Conciseness2/5

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

Description is too brief (one sentence) to be adequately informative; under-specification rather than conciseness.

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?

With 5 parameters, no annotations, and no output schema, the description fails to cover essential aspects like how to obtain page_id, behavior of content_edit_mode, and expected outcomes.

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

Parameters2/5

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

Schema coverage is 0%; description only hints at name and content but does not explain doc_id, page_id, or content_edit_mode enum values.

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

Purpose5/5

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

The description clearly states the verb 'edit' and the resource 'a page inside a ClickUp Doc', and distinguishes from sibling tools like clickup_create_doc and clickup_edit_wiki.

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 on when to use this tool versus alternatives; no prerequisites or context provided.

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

clickup_edit_wikiC

Edit a page inside a ClickUp Wiki (same API as Docs)

ParametersJSON Schema

Name	Required	Description	Default
`wiki_id`	Yes	Wiki doc ID
`page_id`	Yes
`name`	No
`content`	No
`content_edit_mode`	No		replace

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'same API as Docs,' which is vague. There is no mention of destructive behavior, idempotency, or required permissions.

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

Conciseness3/5

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

The description is very short, but conciseness sacrifices essential details. It is front-loaded with the action, but lacks clarity on key aspects.

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?

With no output schema, the description should explain return values, but it does not. The tool has 5 parameters and is a mutation, yet the description is incomplete for an AI agent to use confidently.

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

Parameters1/5

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

Schema description coverage is only 20% (only wiki_id described). The description adds no meaning for page_id, name, content, or content_edit_mode, failing to compensate for the low coverage.

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 'Edit a page inside a ClickUp Wiki' and notes it is the same API as Docs. However, it does not explicitly differentiate from sibling tools like clickup_edit_doc, leaving some ambiguity.

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 (e.g., clickup_edit_doc), no prerequisites, and no when-not-to-use conditions.

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

clickup_list_doc_pagesC

List pages inside a ClickUp Doc or Wiki

ParametersJSON Schema

Name	Required	Description	Default
`doc_id`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

No annotations provided, and the description fails to disclose any behavioral traits such as pagination, error handling, required authentication, or whether the listing is flat or hierarchical. This leaves the agent uninformed about important operational details.

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

Conciseness2/5

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

The description is concise (one sentence) but at the expense of informativeness. It fails to earn its place by providing necessary guidance for correct invocation.

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

Completeness1/5

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

For a tool with one parameter and no annotations or output schema, the description is severely incomplete. It omits details about return format, pagination, errors, and how to handle the required doc_id.

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

Parameters1/5

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

With 0% schema description coverage, the description should compensate but does not. The only parameter, 'doc_id', is not explained (e.g., format, how to obtain it). The description adds no meaning beyond the schema.

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 ('List') and the resource ('pages inside a ClickUp Doc or Wiki'), distinguishing it from siblings like clickup_list_docs (which lists docs, not pages). It is specific and not tautological.

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 on when to use this tool versus alternatives (e.g., clickup_list_docs for top-level docs). The description only states what it does, without any context on prerequisites or suitable scenarios.

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

clickup_list_docsA

Search/list ClickUp Docs and Wikis in the workspace. Use doc_type to filter: doc, wiki, or all.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Search by name
`doc_type`	No		all
`limit`	No

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Search/list' which implies read-only, but does not explicitly state that it is non-destructive, requires no special auth, or describe any side effects. The minimal disclosure leaves the agent underinformed.

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, concise sentence that front-loads the purpose. Every word contributes to understanding the tool's function with no redundancy.

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

Completeness3/5

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

The description covers the basic purpose and doc_type filtering but omits details about the limit parameter, output format, and any behavioral guarantees (e.g., read-only). Given the lack of annotations and output schema, the description is adequate but leaves important gaps.

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 coverage is low (33%), and the description adds meaning for doc_type by explaining its enum values and default. However, the limit parameter has no description in either the schema or the description, leaving its semantics unclear. The description partially compensates but not fully.

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

Purpose5/5

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

The description clearly states the tool searches/lists ClickUp Docs and Wikis, with the ability to filter by doc_type. This distinguishes it from siblings like clickup_list_doc_pages (which lists pages within a doc) and clickup_list_tasks (tasks).

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on using the doc_type parameter to filter results. However, it does not mention when to use this tool versus alternatives like clickup_list_doc_pages or clickup_list_tasks, nor does it state prerequisites or exclusions.

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

clickup_list_tasksA

List ClickUp tasks. Filter by list_id, status, assignee, or search term. Uses team task filter when list_id is omitted.

ParametersJSON Schema

Name	Required	Description
`list_id`	No	ClickUp list ID — if set, lists tasks in this list only
`status`	No	Filter by status name, e.g. 'in progress'
`assignee_id`	No	Filter by assignee user ID
`search`	No	Search in task name and description
`include_closed`	No
`page`	No

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that omitting list_id uses a team task filter, which is useful. However, it lacks details on pagination, rate limits, or auth requirements. More behavioral context would be beneficial.

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?

Two sentences, no wasted words. First sentence captures purpose, second adds key behavioral context. Efficient and well-structured.

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

Completeness3/5

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

No output schema is provided, so the description should hint at return values. It does not mention response format or pagination details. Given 6 parameters and no output information, the description is adequate but not fully complete.

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 67% (4 of 6 parameters described). The description lists filter options but does not add extra semantics beyond the schema. Baseline is appropriate as the schema already explains parameters adequately.

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

Purpose5/5

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

The description clearly states 'List ClickUp tasks' with specific verb and resource. It mentions filtering options and a key behavioral distinction when list_id is omitted, distinguishing it from sibling tools like clickup_update_task.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (listing tasks with filters) and notes the behavior without list_id. However, it does not explicitly state when not to use it or compare with alternatives, though siblings are listed.

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

clickup_update_taskC

Update a ClickUp task by task_id

ParametersJSON Schema

Name	Required	Description
`task_id`	Yes	ClickUp task ID
`name`	No
`description`	No
`status`	No	Status name in the list
`priority`	No	1=urgent, 2=high, 3=normal, 4=low
`due_date`	No	Unix timestamp in milliseconds
`assignees_add`	No	User IDs to add as assignees
`assignees_rem`	No	User IDs to remove from assignees

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 the full burden. It does not disclose whether updates are partial or full, required permissions, side effects, or rate limits. The single sentence is insufficient 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.

Conciseness4/5

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

Extremely concise at one sentence with no wasted words. However, it could benefit from slight expansion without losing efficiency.

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 8 parameters and no output schema, the description is incomplete. It fails to explain partial update behavior, return value, or error scenarios.

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 high (75%). The description adds no additional meaning beyond the schema, but that is acceptable per guidelines (baseline 3).

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 'Update' and the resource 'ClickUp task' with identifier 'task_id'. It is specific but does not elaborate on what can be updated, leaving some ambiguity.

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 siblings like clickup_list_tasks. There are no when-to-use or when-not-to-use instructions.

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.1/5.0

Disambiguation4/5

Tools for docs and wikis are clearly separated, but clickup_list_doc_pages works for both docs and wikis despite its name implying only docs. Otherwise, tasks and docs/wiki domains are distinct.

Naming Consistency5/5

All tools follow a consistent clickup_verb_noun pattern using snake_case, making the set predictable and easy to navigate.

Tool Count5/5

With 8 tools covering docs, wikis, and task operations, the count is well-scoped without being overwhelming or insufficient for the stated purpose.

Completeness2/5

The set lacks basic CRUD operations: no create task, no delete tools for docs, wikis, or tasks, creating notable gaps that will likely cause agent failures.

Maintenance

ActivityStale

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

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
postman-mcp-server
com.postman
A basic MCP server to operate on the Postman API.
API Testing Developer Tools App Automation
3298
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

mcp-clickup
Project Management App Automation
mikah13
A
license
C
quality
C
maintenance
MCP Server for the ClickUp API,
Updated 2 years ago (2025-02-18 13:47 UTC)
4
40
3
MIT
clickup-mcp
Project Management Workplace & Productivity
cvrt-jh
A
license
B
quality
B
maintenance
Lightweight ClickUp MCP server for task management with 37 tools and token-optimized responses to reduce API verbosity.
Updated 22 days ago (2026-08-12 14:58 UTC)
37
64
3
MIT
ClickUp MCP Server
Project Management Workplace & Productivity
ttttdiva
A
license
B
quality
D
maintenance
MCP server for ClickUp task management, enabling task search, creation, update, deletion, workspace info retrieval, and comment management via ClickUp API v2.
Updated 6 months ago (2026-02-27 05:49 UTC)
15
65
MIT
Pryazilim ClickUp MCP Server
Project Management Workplace & Productivity
karaokmert
A
license
Not graded
quality
C
maintenance
A secure and optimized MCP server for integrating ClickUp project management, enabling task CRUD operations, workspace organization, file attachments, and natural language date parsing.
Updated a year ago (2025-09-23 14:51 UTC)
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/lucaspsantana/clickup-mcp-server'

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

clickup-custom-mcp

Início rápido

Credenciais

Onde colocar (em ordem de prioridade)

.env (recomendado)

Variáveis de ambiente do sistema

O que o npm run setup faz

Opções do script

Arquivos que o script escreve

Auto-detecção de IDEs

Ferramentas disponíveis

clickup (oficial) vs clickup-custom

Configuração manual (alternativa)

1. Registrar binário

2. Bloco de configuração

Config por IDE

Atualizar

Solução de problemas

Setup falhou com "Credenciais ausentes"

Servidor não aparece no IDE

Erro CLICKUP_API_KEY is required

Erro 401 / 403 da API ClickUp

VS Code: config do Cursor não funciona

Kiro: binário não encontrado

WSL2

Teste manual do servidor

Estrutura do projeto

Scripts

Segurança

Pré-requisitos

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`.env` (recomendado)

O que o `npm run setup` faz

Erro `CLICKUP_API_KEY is required`