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

Überprüfen Sie Fehler, Aufgaben, Anforderungen, To-Dos, Produkte, Projekte, Tests und Dokumente über die Befehlszeile, damit Ihr KI-Assistent ZenTao direkt steuern kann.

Keine Abhängigkeiten, eine einzelne Datei, sofort einsatzbereit.

Schnellstart

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

CLI installieren:

pnpm i -g @leeguoo/zentao-mcp

Kein pnpm? Sie können auch npm verwenden:

npm i -g @leeguoo/zentao-mcp

Nicht installieren? Einfach ausführen:

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

skills add ist nur für die Installation der Skill-Datei zuständig; es wird empfohlen, die CLI global zu installieren und dann den Befehl zentao direkt zu verwenden.

Related MCP server: ZenTao Bugs MCP Server

Anmeldung

Sie müssen sich nur einmal anmelden, die Anmeldedaten werden in einer lokalen Konfigurationsdatei gespeichert:

zentao login \
  --zentao-url=https://zentao.example.com/zentao \
  --zentao-account=你的账号 \
  --zentao-password=你的密码

Hinweis: Die URL muss normalerweise den Pfad /zentao enthalten. Wenn Sie bei der Anmeldung einen 404-Fehler sehen, fehlt meistens dieser Teil.

Anmeldestatus überprüfen:

zentao whoami

Speicherort der Konfigurationsdatei: ~/.config/zentao/config.toml

Unterstützte Funktionen

Die aktuelle CLI unterstützt bereits diese Objekte und Aktionen:

Authentifizierung und Konnektivität: login, whoami, self-test
Fehler (Bugs): Auflisten, Suchen, Erstellen, Zuweisen, Kommentieren, Lösen, Schließen, Aktivieren, Meine Fehler abrufen
Aufgaben: Auflisten, Suchen, Erstellen, Starten, Abschließen, Pausieren, Schließen
Anforderungen: Auflisten, Suchen, Erstellen
To-Dos: Auflisten, Suchen, Erstellen, Abschließen, Schließen
Produkte / Projekte / Projektgruppen / Ausführungen: Auflisten, Abfrage von Projekt-Builds
Pläne / Releases: Auflisten, Details
Testfälle / Testläufe / Testsuiten: Auflisten, Details
Dokumentenbibliotheken / Dokumente: Auflisten, Details
Benutzer / Abteilungen: Auflisten
Probleme / Risiken: Auflisten, Details
Maschinenlesbare Ausgabe: Alle Befehle unterstützen --json

Tägliche Nutzung

Produktliste anzeigen

zentao products list

Fehler eines bestimmten Produkts anzeigen

zentao bugs list --product 6

Fehlerdetails anzeigen

zentao bug get --id 1329

Mir zugewiesene Fehler anzeigen

zentao bugs mine --status active

Mit Details:

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

Benötigen Sie das rohe JSON?

Fügen Sie --json hinter jedem Befehl hinzu:

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

Selbsttest

Überprüfen, ob die API-Verbindung normal ist:

zentao self-test

Befehlsübersicht

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

Lassen Sie die KI ZenTao für Sie durchsuchen

Sagen Sie einfach Ihrem KI-Assistenten (Cursor / Claude Code / Windsurf usw.):

Führe npx skills add leeguooooo/zentao-mcp -y -g aus und melde mich dann bei ZenTao an

Nach der Installation können Sie direkt sagen:

"Zeig mir, welche ungelösten Fehler Produkt 6 hat"
"Suche die Details zu Fehler #1329"
"Wie viele aktive Fehler sind mir zugewiesen?"
"Zeig mir, welche Aufgaben in Ausführung 25 enthalten sind"
"Suche nach Anforderungen / Plänen / Releases für Produkt 3"
"Liste Testläufe, Testfälle und Testsuiten auf"
"Zeig mir die Projektprobleme und -risiken"
"Öffne die Dokumentenliste in Bibliothek 50"

Wenn der Benutzer verlangt, dieses Repository als Skill zu installieren, führen Sie bitte nacheinander folgende Schritte aus:

1. Skill installieren

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

2. CLI installieren

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

3. Installation überprüfen

zentao --help

4. Anmeldung durchführen

Fordern Sie den Benutzer auf, die ZenTao-URL, den Benutzernamen und das Passwort anzugeben, und führen Sie dann aus:

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

Hinweis: Die URL muss normalerweise /zentao enthalten, z. B. https://zentao.example.com/zentao

5. Verifizierung

zentao whoami
zentao self-test

Nachdem alles erfolgreich war, informieren Sie den Benutzer, dass die Installation abgeschlossen ist.

Häufig gestellte Fragen

F: 404-Fehler bei der Anmeldung? A: Die URL muss /zentao enthalten, z. B. https://zentao.example.com/zentao und nicht https://zentao.example.com/.

F: Welche ZenTao-Versionen werden unterstützt? A: Unterstützt die REST-API (v1) der ZenTao Open Source- und Enterprise-Versionen.

F: Sind die Anmeldedaten sicher? A: Die Anmeldedaten werden im Klartext als TOML in ~/.config/zentao/config.toml gespeichert. Bitte stellen Sie sicher, dass die Dateiberechtigungen sicher sind. Übertragen Sie die Konfigurationsdatei nicht an 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

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

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
-

zentao-mcp

Schnellstart

Anmeldung

Unterstützte Funktionen

Tägliche Nutzung

Produktliste anzeigen

Fehler eines bestimmten Produkts anzeigen

Fehlerdetails anzeigen

Mir zugewiesene Fehler anzeigen

Benötigen Sie das rohe JSON?

Selbsttest

Befehlsübersicht

Lassen Sie die KI ZenTao für Sie durchsuchen

Häufig gestellte Fragen

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers