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

⚠️ 本项目不再维护。 推荐改用禅道官方维护的 zentao-cli 和配套 Skills easysoft/zentao-skills：基于 RESTful API v2、内置 MCP server、模块覆盖更全，且持续更新。
已经在用本包的用户不受影响，可以继续装；新项目请优先选择上游：
npm i -g zentao-cli
npx skills add easysoft/zentao-skills

在命令行里查 Bug、任务、需求、待办、产品、项目、测试和文档，让你的 AI 助手也能直接操作禅道。

零依赖、单文件，装完即用。

快速开始

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 只负责安装 skill 文件；CLI 仍然建议全局安装后直接用 zentao 命令。

Related MCP server: ZenTao Bugs MCP Server

升级

zentao self-update --check   # 只看当前版本和最新版本，不改任何东西
zentao self-update           # 确认后用原来安装它的 npm / pnpm 升级（脚本里加 --yes）
zentao self-update --to 0.7.0 --yes   # 装指定版本

只读取 npm registry 的公开版本信息，再调用当初安装它的包管理器（npm i -g 或 pnpm add -g）。npx 运行、git 源码目录或识别不出来的安装方式不会被改动，只给出手动升级命令。
不登录禅道，不改 ~/.config/zentao/config.toml，不发版。升级后会核对版本并离线跑一次 --help，失败就装回原来的版本。
--json 输出 current / target / result 等字段，方便脚本和 AI 助手读取。
skill 文件要单独更新：重新执行 npx skills add leeguooooo/zentao-mcp -y -g（会覆盖你对 SKILL.md 的本地修改）。
zentao release 是维护者发版用的，不是升级命令。
本包已停止新功能开发；self-update 只会升级本包，不会自动换成官方 zentao-cli。

支持的能力

当前 CLI 已支持这些对象和动作：

认证与连通性：login、whoami、self-test
Bug：列表、查询、创建、指派、评论、解决、关闭、激活、查我的 Bug
任务：列表、查询、创建、开始、完成、暂停、关闭
需求：列表、查询、创建
待办：列表、查询、创建、完成、关闭
产品 / 项目 / 项目集 / 执行：列表，项目构建查询
计划 / 发布：列表、详情
测试用例 / 测试单 / 测试套件：列表、详情
文档库 / 文档：列表、详情
用户 / 部门：列表
问题 / 风险：列表、详情
机器可读输出：全部命令支持 --json

日常使用

查看产品列表

zentao products list

查看某个产品的 Bug

zentao bugs list --product 6

查看 Bug 详情

zentao bug get --id 1329

查看分配给我的 Bug

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 self-update --check

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 帮你查禅道

只需对你的 AI 助手（Cursor / Claude Code / Windsurf 等）说：

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

安装后你就可以直接说：

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

当用户要求安装本仓库为 skill 时，请按顺序执行：

1. 安装 Skill

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. 引导登录

提示用户提供禅道 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: 支持哪些禅道版本？ A: 支持禅道开源版和企业版的 REST API（v1）。

Q: 凭据安全吗？ A: 凭据以明文 TOML 存储在 ~/.config/zentao/config.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
-