clickup-mcp
clickup-mcp
ClickUp MCPサーバー(Claude用) — ClickUpのタスク、スペース、フォルダ、リスト、コメントをMCPツールとして公開します。
技術スタック: Python 3.12 + uv + FastMCP (Starlette/FastAPI)
クイックスタート
# Install dependencies
cd D:\leo\mcp-server\clickup-mcp
uv sync
# Run in stdio mode (for Claude Desktop)
$env:CLICKUP_API_TOKEN="pk_xxxxx"
uv run clickup-mcpRelated MCP server: Clickup Universal MCP Server
設定
.env.example を .env にコピーし、値を入力してください:
変数 | デフォルト値 | 説明 |
| — | ClickUp個人用APIトークン ( |
|
|
|
|
|
|
|
| HTTPサーバーポート |
|
| APIベースURL |
APIトークンを取得するには:ClickUp → 設定 → アプリ → APIトークン
Claude Desktopのセットアップ
claude_desktop_config.json に追加:
{
"mcpServers": {
"clickup": {
"command": "uv",
"args": ["run", "--directory", "D:/leo/mcp-server/clickup-mcp", "clickup-mcp"],
"env": {
"CLICKUP_API_TOKEN": "pk_xxxxx"
}
}
}
}トランスポートモード
stdio (Claude Desktop / CLI)
$env:CLICKUP_API_TOKEN="pk_xxxxx"
uv run clickup-mcpHTTP — シングルテナント
$env:CLICKUP_API_TOKEN="pk_xxxxx"
$env:MCP_TRANSPORT="http"
$env:MCP_HTTP_PORT="8080"
uv run clickup-mcpHTTP — ゲートウェイ / マルチテナント
$env:MCP_TRANSPORT="http"
$env:AUTH_MODE="gateway"
uv run clickup-mcp
# Each request must include: X-Clickup-Token: pk_xxxxx利用可能なツール (28)
ツール | 説明 |
| すべてのワークスペース/チームを一覧表示 |
| ワークスペースメンバーを一覧表示(id/username/email/team_id/roleにフラット化) — メールアドレスから |
| ワークスペース内のスペースを一覧表示 |
| スペースの詳細を取得 |
| スペース内のフォルダを一覧表示 |
| スペース内のフォルダなしリストを一覧表示 |
| フォルダの詳細を取得 |
| フォルダ内のリストを一覧表示 |
| フォルダを作成 |
| フォルダを更新 |
| フォルダを削除 |
| リストの詳細を取得 |
| フォルダ内にリストを作成 |
| スペース内にリストを作成 |
| リストを更新 |
| IDでタスクを取得 |
| フィルターでタスクを検索(単一ワークスペース、team_id 必須) |
| 1回の呼び出しで、メールまたは user_id により、表示可能なすべてのワークスペースにわたって個人のタスクを一覧表示 — team_id、手動ページネーション/重複排除は不要 |
| タスクを作成 |
| タスクを更新 |
| タスクを削除 |
| タスクを別のリストに移動 |
| タスクのコメントを取得 |
| タスクにコメントを追加 |
| ドキュメント (v3) から1ページを取得 |
| ファイル(例:画像)をタスクの添付ファイルとしてアップロード |
| ファイルをアップロードし、1回の呼び出しで新しいタスクコメント内にインラインで投稿 |
| 組織全体のすべてのEOS Rocks(四半期目標)を1回の呼び出しで一覧表示、固定されたステータス列挙型に正規化 |
個人のClickUpユーザーIDを見つける
clickup_list_members を使用します。ClickUpのネイティブ GET /team レスポンスはチームごとに完全なメンバーリストを埋め込みますが (teams[].members[].user.{id,username,email})、clickup_get_workspaces はレスポンスを小さく保つためにそれを取り除くため、人物を検索する場所としては適していません。clickup_list_members は同じ基盤エンドポイントを読み取り、メンバーリストをフラットで目的に特化した形状 (id/username/email/team_id/role) に投影するため、呼び出し元が完全なワークスペース/チームオブジェクトから自分で掘り出す必要はありません。clickup_list_tasks_for_person は内部的に同じルックアップを使用して email を user_id に解決します。
既知のギャップ:ClickUpのチームメンバーオブジェクトには、信頼できる「このメンバーは無効化されているか」フィールドがありません — clickup_list_members は active フィールドを返しません。なぜなら、それを裏付ける実際のデータが存在しないからです(生のオブジェクトに存在する唯一の status フィールドである invited_by.status は、招待者を説明するものであり、メンバーを説明するものではありません)。
clickup_search_tasks はすでに status.type を返します
ここにある他のすべての読み取りツールと同様に、clickup_search_tasks と clickup_get_task はClickUpの生のタスクオブジェクトを変更せずにそのまま通過させます — これには status オブジェクトの type フィールド (open / custom / closed / done) も含まれます。これは、カスタム名のステータスが完了とみなされるかどうかを判断する唯一の信頼できる方法です。このためのコード変更は必要ありませんでした。すでに存在していました。clickup_list_tasks_for_person は、利便性のために返される各タスクに status_type として明示的に表示します。
EOS RocksがこのClickUpワークスペースでどのように表現されるか
実際のロックタスクのフィールドを直接検査して確認済み(2026-08-18、推測ではありません):Rocksは、文字通り「Rocks」という名前のリストに存在する通常のClickUpタスクです(スペース「Company」> フォルダ「EOS Traction」の下にあります)。それぞれに専用のカスタムフィールドがあります:Quarter(ドロップダウン、"Q1 2024".."Q4 2026")、Rocks Status(On Hold / Off Track / On Track / Completed / Blocked / At Risk)、Rock Type(Company / Individual / Departmental / Team Rock)、Department、および Progress(手動)または Progress %(自動、チェックリストロールアップ)のいずれかによる進捗状況。これはClickUp Goals APIでも、メタデータのない単純なタスクリストでもありません — タスクとカスタムフィールドの組み合わせです。
clickup_list_rocks_for_org は、トークンから見えるすべてのワークスペースにわたって「Rocks」という名前のすべてのリストを(ハードコードされたIDではなく名前で、スペース/フォルダが再編成される場合に備えて)検出し、これらのフィールドを読み取り、正規化します:
quarter:ClickUpの「Q3 2026」ラベルは2026-Q3に変換されます(およびその逆も、quarter入力フィルター用)。status:ClickUpの6つの生のオプションは、5つの値の契約 (on_track/off_track/done/missed/open) にマッピングされます — 正確なマッピングと、missedが決して出力されない理由については、rocks.pyの_STATUS_MAPコメントを参照してください(ClickUpのデータで「時間切れ」と一般的な「軌道から外れている」を区別するものは何もなく、期限切れの due_date からそれを導出することは未確認のビジネスロジックの仮定となるため、ここでは行われていません)。measurable:このリストには専用のフィールドは存在しません。タスクの説明にフォールバックします。それも空の場合はnull(決して作り出されません)。weekly_status:構造化されたソースはどこにも見つかりませんでした(カスタムフィールドでも、コメントから派生したものでもありません) — 常に[]として返されます。組織がこれをClickUpで他の方法で追跡し始めた場合は、再検討してください。
添付ファイルと画像
ClickUpのREST APIには、ファイルをコメントに直接添付する方法はありません — タスクにのみ添付できます(POST /task/{task_id}/attachment、clickup_attach_task_file がラップするもの)。また、添付ファイルを削除/更新するエンドポイントもありません。再アップロードすると古い添付ファイルを置き換えるのではなく新しい添付ファイルが追加され、削除するにはClickUpのWeb/デスクトップアプリが必要です。ClickUp自身の公式MCPサーバーのツール説明を確認しても確認済みです — 同じ分割です(添付ファイルをサポートしない Create Task Comment ツールと、別の Attach File to Task ツール)。
コメント内に画像をインラインで表示させるには、基本的なトリックは次のとおりです:まずファイルをタスクにアップロードし、次にファイルのレスポンスから返されたURLをコメントテキスト内のMarkdown画像構文で参照します — ClickUpのコメントレンダラーはそれを単なるリンクではなく実際の画像としてインライン表示します。clickup_create_comment_with_image は両方のステップを1回の呼び出しで実行します:
clickup_create_comment_with_image(task_id, file_content_base64, filename)
# internally:
# 1. POST /task/{task_id}/attachment -> {"url": "...", ...}
# 2. POST /task/{task_id}/comment comment_text = ""代わりに手動で行う場合(例:画像の周りに他のテキストを追加するため)、2つのツールを自分で呼び出します:
1. result = clickup_attach_task_file(task_id, file_content_base64, filename)
-> result["url"] is the uploaded file's URL
2. clickup_create_task_comment(
task_id,
comment_text=f""
)APIリファレンス
Available Tools
1 toolclickup_test_connectionA
Test ClickUp connection. Shows configuration requirements when credentials are missing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is a test operation and shows config requirements on failure. No annotations, so description carries full burden. Does not clarify if it is read-only, has side effects, or what output format looks like (though output schema exists). Minimal disclosure.
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 concise sentences, front-loaded with purpose. No extraneous words. Efficient and clear.
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?
Simple tool with no parameters and low complexity. Description covers purpose and a key failure behavior. Output schema exists to document return values, so completeness is high. Minor gap: could mention safe/read-only nature explicitly.
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, so input schema is empty. Description adds meaning by explaining tool purpose and special behavior. Baseline for 0 params is 4; description fulfills this adequately.
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?
Clear verb ('Test') and resource ('ClickUp connection'), with specific additional behavior: shows configuration requirements when credentials missing. No sibling tools to differentiate, but purpose is unambiguous.
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?
Implied usage: use to verify connection and get config hints if incomplete. No explicit when-to-use, when-not-to-use, or alternatives provided. Lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
clickup_test_connection
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools.
With a single tool, naming consistency is not applicable, but the tool name follows a clear verb_noun pattern.
A single 'test connection' tool is severely insufficient for a platform like ClickUp, which typically requires many tools for tasks, issues, lists, etc.
The tool only tests the connection, lacking any actual CRUD operations or meaningful interactions with ClickUp resources.
Maintenance
Related MCP Connectors
ClickUp MCP — wraps the ClickUp REST API v2 (BYO API key)
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
Manage Timequip projects, tasks, comments, members, and dashboards through MCP.
Read and write shared BitsWeave context, projects, tasks, and work sessions through MCP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides integration with ClickUp's API, allowing you to retrieve task information and manage ClickUp data through MCP-compatible clients.-
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Clickup's project management tools through the MCP protocol, allowing task and project operations via natural language.1MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI applications to interact with ClickUp's project management API through the MCP protocol, supporting resources like Teams, Spaces, Goals, and Key Results.26 PyPI4MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to manage ClickUp workspaces, teams, spaces, folders, lists, tasks, and custom fields via 29 MCP tools with full CRUD operations.28 npm5MIT