de en es ja ko ru zh

ZenTao MCP Server

Name: ZenTao MCP Server
Author: leeguooooo

by leeguooooo

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

zentao-mcp

コマンドラインからバグ、タスク、要件、ToDo、製品、プロジェクト、テスト、ドキュメントを検索し、AIアシスタントが直接ZenTao（禅道）を操作できるようにします。

依存関係ゼロ、単一ファイルで、インストール後すぐに使用可能です。

クイックスタート

npx skills add leeguooooo/zentao-mcp -y -g

CLIのインストール：

pnpm i -g @leeguoo/zentao-mcp

pnpmがない場合、npmも使用可能です：

npm i -g @leeguoo/zentao-mcp

インストールしたくない場合、直接実行：

npx -y @leeguoo/zentao-mcp --help

skills add はスキルファイルのインストールのみを行います。CLIはグローバルインストール後に zentao コマンドとして直接使用することを推奨します。

Related MCP server: ZenTao Bugs MCP Server

サポートされている機能

現在のCLIは以下のオブジェクトとアクションをサポートしています：

認証と接続性：login、whoami、self-test
バグ：一覧、検索、作成、割り当て、コメント、解決、クローズ、アクティブ化、自分のバグの確認
タスク：一覧、検索、作成、開始、完了、一時停止、クローズ
要件：一覧、検索、作成
ToDo：一覧、検索、作成、完了、クローズ
製品 / プロジェクト / プロジェクトセット / 実行：一覧、プロジェクトビルド検索
計画 / リリース：一覧、詳細
テストケース / テストオーダー / テストスイート：一覧、詳細
ドキュメントライブラリ / ドキュメント：一覧、詳細
ユーザー / 部門：一覧
問題 / リスク：一覧、詳細
機械可読出力：すべてのコマンドが --json をサポート

日常的な使用

製品一覧の表示

zentao products list

特定製品のバグ表示

zentao bugs list --product 6

バグ詳細の表示

zentao bug get --id 1329

自分に割り当てられたバグの表示

zentao bugs mine --status active

詳細付き：

zentao bugs mine --status active --include-details

生のJSONが必要な場合

任意のコマンドの後に --json を追加：

zentao products list --json
zentao bugs list --product 6 --json
zentao bug get --id 1329 --json
zentao bugs mine --include-details --json

自己診断

API接続が正常か確認：

zentao self-test

コマンド概要

zentao login --zentao-url=... --zentao-account=... --zentao-password=...
zentao whoami
zentao self-test

zentao products list
zentao programs list
zentao projects list
zentao projects builds --id 22
zentao executions list

zentao bugs list --product 6
zentao bugs mine --status active --include-details
zentao bug get --id 1329
zentao bug create --product 6 --title "bug title"
zentao bug assign --id 1329 --assigned-to someone
zentao bug resolve --id 1329 --resolution fixed
zentao bug close --id 1329
zentao bug activate --id 1329
zentao bug comment --id 1329 --comment "comment"

zentao tasks list --execution 25
zentao task get --id 388
zentao task create --execution 25 --name "task name"
zentao task start --id 388
zentao task finish --id 388
zentao task pause --id 388
zentao task close --id 388

zentao stories list --product 3
zentao story get --id 1
zentao story create --product 3 --title "story title"

zentao todos list
zentao todos get --id 1
zentao todos create --name "todo name"
zentao todos finish --id 1
zentao todos close --id 1

zentao plans list --product 3
zentao plans get --id 1
zentao releases list --product 3
zentao releases get --id 1

zentao testcases list --product 3
zentao testcases get --id 1
zentao testtasks list
zentao testtasks get --id 1
zentao testsuites list --product 3
zentao testsuites get --id 1

zentao docs libs
zentao docs list --lib 50
zentao docs get --id 1
zentao users list
zentao departments list
zentao issues list
zentao issues get --id 1
zentao risks list
zentao risks get --id 1

AIにZenTaoの検索を任せる

AIアシスタント（Cursor / Claude Code / Windsurfなど）に次のように伝えるだけです：

帮我执行 npx skills add leeguooooo/zentao-mcp -y -g，然后帮我登录禅道

インストール後、直接以下のように指示できます：

"帮我看下产品 6 有哪些未解决的 Bug"
"查一下 Bug #1329 的详情"
"我名下还有多少活跃 Bug？"
"帮我看执行 25 下有哪些任务"
"查一下产品 3 的需求 / 计划 / 发布"
"列出测试单、测试用例、测试套件"
"看一下项目问题和风险"
"打开文档库 50 里的文档列表"

ユーザーが本リポジトリをスキルとしてインストールするよう要求した場合、以下の順序で実行してください：

1. スキルのインストール

npx skills add leeguooooo/zentao-mcp -y -g

2. CLIのインストール

pnpm i -g @leeguoo/zentao-mcp || npm i -g @leeguoo/zentao-mcp

3. インストールの検証

zentao --help

4. ログインの案内

ユーザーにZenTaoのURL、アカウント、パスワードの入力を促し、以下を実行します：

zentao login --zentao-url="<用户的禅道URL>" --zentao-account="<账号>" --zentao-password="<密码>"

注意：URLには通常 /zentao を含める必要があります（例：https://zentao.example.com/zentao）

5. 検証

zentao whoami
zentao self-test

すべて完了したら、ユーザーにインストールが完了したことを伝えてください。

よくある質問

Q: ログイン時に404エラーが出るのはなぜ？ A: URLに /zentao を含める必要があります。例：https://zentao.example.com/zentao （https://zentao.example.com/ ではありません）。

Q: どのZenTaoバージョンをサポートしていますか？ A: ZenTaoオープンソース版およびエンタープライズ版のREST API（v1）をサポートしています。

Q: 認証情報は安全ですか？ A: 認証情報は ~/.config/zentao/config.toml にプレーンテキストのTOML形式で保存されます。ファイルのアクセス権限を適切に管理してください。設定ファイルをGitにコミットしないでください。

リンク

Available Tools

4 tools

zentao_bug_getC

Get bug details (获取Bug详情) by bug ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Bug ID (required).

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 this is a read operation ('Get'), but doesn't mention authentication needs, rate limits, error handling, or what the return format looks like (e.g., JSON structure). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 extremely concise and front-loaded, consisting of a single, efficient sentence with bilingual phrasing. Every word earns its place, and there's no wasted verbiage, 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 lack of annotations and output schema, the description is incomplete for a tool that retrieves details. It doesn't explain what 'bug details' include (e.g., fields returned), error cases, or dependencies. For a read operation with no structured output information, this leaves the agent under-informed about the tool's full context.

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%, with the parameter 'id' fully documented as 'Bug ID (required).' The description adds minimal value beyond this by reiterating 'by bug ID', but doesn't provide additional context like valid ID ranges or examples. With high schema coverage, the baseline score of 3 is appropriate.

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 tool's purpose: 'Get bug details by bug ID.' It specifies the verb ('Get') and resource ('bug details'), and the bilingual phrasing adds clarity. However, it doesn't explicitly distinguish this tool from its sibling 'zentao_bugs_list', which might also retrieve bug details in a list format.

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 'zentao_bugs_list' or 'zentao_bugs_mine'. It implies usage by stating 'by bug ID', but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage scenarios.

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

zentao_bugs_listA

List bugs (缺陷/问题) for a specific product in ZenTao. Use this when user asks to 'see bugs', 'view bugs', 'show bugs', '看bug', '查看bug', '显示bug', or wants to check issues for a product. Requires product ID which can be obtained from zentao_products_list.

ParametersJSON Schema

Name	Required	Description
`product`	Yes	Product ID (required). Get this from zentao_products_list first.
`page`	No	Page number (default 1).
`limit`	No	Page size (default 20).

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It clearly indicates this is a read operation ('List bugs'), but doesn't disclose behavioral traits like pagination behavior (implied by page/limit parameters), rate limits, authentication requirements, or what the return format looks like. It adds some context about the prerequisite but lacks comprehensive behavioral details.

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 efficiently structured in two sentences: the first states the purpose and usage context, the second provides the prerequisite. Every sentence adds value with no redundant information, and it's appropriately front-loaded with the core functionality.

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?

For a list operation with 3 parameters and no output schema, the description provides adequate purpose and usage guidance but lacks details about return format, pagination behavior, or error conditions. The absence of annotations means the description should do more to cover behavioral aspects, though it successfully addresses the core use case and prerequisites.

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 already fully documents all three parameters. The description adds minimal value beyond the schema by mentioning the product ID prerequisite, but doesn't provide additional semantic context about parameter usage or relationships. This meets the baseline for high schema coverage.

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 specific action ('List bugs') and resource ('for a specific product in ZenTao'), distinguishing it from sibling tools like zentao_bug_get (single bug) and zentao_bugs_mine (user-specific bugs). It provides both English and Chinese terminology for clarity.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('when user asks to see/view/show bugs or wants to check issues for a product') and provides alternative phrasing in both English and Chinese. It also mentions a prerequisite ('Requires product ID which can be obtained from zentao_products_list') and implicitly distinguishes from siblings by focusing on product-specific listing.

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

zentao_bugs_mineA

List my bugs (我的Bug) by assignment or creator. Default scope is assigned. Use when user asks for 'my bugs', '我的bug', '分配给我', or personal bug list.

ParametersJSON Schema

Name	Required	Description
`account`	No	Account to match (default: login account).
`scope`	No	Filter scope: assigned\|opened\|resolved\|all (default assigned).
`status`	No	Status filter: active\|resolved\|closed\|all (default active).
`productIds`	No	Optional product IDs to limit search.
`includeZero`	No	Include products with zero matches (default false).
`perPage`	No	Page size when scanning products (default 100).
`maxItems`	No	Max bug items to return (default 200).
`includeDetails`	No	Include bug details list (default false).

TDQS

A4.1/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 the full burden. It mentions the default scope ('assigned') and includes examples of user queries, which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination behavior, or what the response looks like (e.g., format, error handling). For a tool with 8 parameters and no annotations, this is a moderate gap.

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 concise and front-loaded: it states the purpose in the first sentence, provides usage guidelines in the second, and includes specific query examples. Every sentence earns its place with no wasted words, making it efficient for an AI agent to parse.

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?

Given the tool's complexity (8 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers purpose and usage well, but lacks behavioral details like response format, error cases, or performance considerations. With no output schema, it should ideally hint at return values, but it doesn't, leaving some context incomplete.

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 already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it implies the 'scope' parameter with 'Default scope is assigned' but doesn't explain other parameters like 'account' or 'status'. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'List my bugs (我的Bug) by assignment or creator.' It specifies the verb ('List'), resource ('my bugs'), and scope ('by assignment or creator'), and distinguishes it from siblings by focusing on personal bug lists rather than general bug listing or product listing.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: 'Default scope is assigned. Use when user asks for 'my bugs', '我的bug', '分配给我', or personal bug list.' It specifies when to use the tool (personal bug queries) and implies alternatives (e.g., zentao_bugs_list for non-personal lists), though it doesn't name siblings directly.

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

zentao_products_listA

List all products from ZenTao. Use this to get product IDs before querying bugs. Returns product information including ID, name, and bug counts.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (default 1).
`limit`	No	Page size (default 1000).

TDQS

A4.2/5.0

Behavior3/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 mentions the return format ('product information including ID, name, and bug counts') which is helpful, but doesn't address important behavioral aspects like pagination behavior (implied by parameters but not explained), error conditions, or authentication requirements. The description adds some value but leaves gaps.

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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose, and the second provides usage guidance and return format information. No wasted words or redundancy.

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

Completeness4/5

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

For a list tool with no annotations and no output schema, the description provides good context about purpose, usage, and return format. However, it doesn't fully compensate for the lack of output schema by detailing the exact structure of returned product information or addressing pagination behavior. Given the tool's relative simplicity, it's mostly complete but has minor 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 description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 ('List') and resource ('all products from ZenTao'), and distinguishes this tool from its siblings by specifying it's for getting product IDs before querying bugs. It explicitly mentions the sibling tools are for bugs, while this is for products.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool ('to get product IDs before querying bugs') and implicitly suggests alternatives by mentioning sibling bug-related tools. It establishes a clear workflow context for usage.

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.

4 tool updatesv1.0.0Jan 5, 2026
- First observedzentao_bug_get
- First observedzentao_bugs_list
- First observedzentao_bugs_mine
- First observedzentao_products_list

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored 2026-04-18 07:46 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: zentao_bug_get retrieves a specific bug by ID, zentao_bugs_list lists bugs for a product, zentao_bugs_mine lists personal bugs, and zentao_products_list lists products. There is no overlap in functionality, and the descriptions explicitly differentiate their use cases, preventing misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a 'zentao_' prefix and a clear verb_noun structure (e.g., 'bug_get', 'bugs_list', 'bugs_mine', 'products_list'). This predictability makes it easy for agents to understand and navigate the tool set without confusion.

Tool Count4/5

With 4 tools, the count is reasonable for a ZenTao bug tracking server, covering core operations like listing products, viewing bugs, and personal bug lists. However, it feels slightly thin as it lacks tools for creating, updating, or deleting bugs, which are common in such domains, but the existing tools are well-scoped.

Completeness2/5

The tool set has significant gaps for a bug tracking system. It only supports read operations (get and list) for bugs and products, missing essential CRUD functionality such as creating, updating, or deleting bugs. This will likely cause agent failures when users need to perform these actions, making the surface incomplete for the domain.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

Testiny Test Management AOAuth
io.testiny
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Testing & QA Tools Project Management
152
Loom
io.github.abhinand-adviciya
Manage Loom projects, tasks, bugs, defects, clients and phases from AI assistants
Project Management Testing & QA Tools
1
ONESOAuth
com.ones
Manage ONES projects, issues, tests, work hours, and Wiki knowledge.
Project Management Testing & QA Tools Documentation Access
1
Astravue MCPOAuth
com.astravue
Manage projects, tasks, time tracking, and team collaboration through natural language.
Project Management Workplace & Productivity
312

Related MCP Servers

ZenTao MCP Server
Project Management Developer Tools App Automation
godlewis
F
license
Not graded
quality
D
maintenance
Enables LLMs to interact with ZenTao project management system, supporting project and task management operations including creating, querying, and updating projects and tasks through natural language.
Updated 10 months ago (2025-12-22 15:29 UTC)
5
-
ZenTao Bugs MCP Server
Testing & QA Tools Project Management Developer Tools
evlon
A
license
Not graded
quality
D
maintenance
Enables interaction with ZenTao bug tracking system to search products, query assigned bugs, view bug details with extracted images, and mark bugs as resolved through natural language commands.
Updated a year ago (2025-11-06 10:10 UTC)
9 npm
7
ISC
ZenTao MCP Server
Project Management Developer Tools App Automation
Valiant-Cat
F
license
B
quality
C
maintenance
Enables interaction with ZenTao project management system through RESTful API v1. Supports bug tracking, project/product management, and automated token authentication for seamless integration.
Updated 10 months ago (2025-12-12 06:37 UTC)
10
14 npm
1
-
Zentao MCP Server
Project Management Testing & QA Tools Developer Tools
Tytt
F
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Zentao bugs, requirements, and test cases through natural language interactions. It supports querying, creating, and updating various Zentao data entities including products, projects, and executions.
Updated 9 months ago (2026-01-23 02:56 UTC)
13 npm
12
-