ZenTao MCP Server
zentao-mcp
Consulta errores, tareas, requisitos, pendientes, productos, proyectos, pruebas y documentos desde la línea de comandos, permitiendo que tu asistente de IA opere directamente en ZenTao.
Sin dependencias, archivo único, listo para usar tras la instalación.
Inicio rápido
npx skills add leeguooooo/zentao-mcp -y -gInstalar la CLI:
pnpm i -g @leeguoo/zentao-mcp¿No tienes pnpm? También puedes usar npm:
npm i -g @leeguoo/zentao-mcp¿No quieres instalarlo? Ejecútalo directamente:
npx -y @leeguoo/zentao-mcp --helpskills add solo se encarga de instalar el archivo skill; se recomienda instalar la CLI globalmente y usar el comando zentao.
Related MCP server: ZenTao Bugs MCP Server
Inicio de sesión
Solo necesitas iniciar sesión una vez, las credenciales se guardarán en el archivo de configuración local:
zentao login \
--zentao-url=https://zentao.example.com/zentao \
--zentao-account=你的账号 \
--zentao-password=你的密码Nota: La URL generalmente necesita incluir la ruta
/zentao. Si ves un error 404 al iniciar sesión, es probable que falte esta parte.
Verificar el estado de inicio de sesión:
zentao whoamiUbicación del archivo de configuración: ~/.config/zentao/config.toml
Capacidades admitidas
Actualmente, la CLI admite estos objetos y acciones:
Autenticación y conectividad:
login,whoami,self-testErrores (Bugs): listar, consultar, crear, asignar, comentar, resolver, cerrar, activar, consultar mis errores
Tareas: listar, consultar, crear, iniciar, completar, pausar, cerrar
Requisitos: listar, consultar, crear
Pendientes: listar, consultar, crear, completar, cerrar
Productos / Proyectos / Programas / Ejecuciones: listar, consulta de construcción de proyectos
Planes / Lanzamientos: listar, detalles
Casos de prueba / Suites de prueba / Ejecuciones de prueba: listar, detalles
Bibliotecas de documentos / Documentos: listar, detalles
Usuarios / Departamentos: listar
Problemas / Riesgos: listar, detalles
Salida legible por máquina: todos los comandos admiten
--json
Uso diario
Ver lista de productos
zentao products listVer errores de un producto específico
zentao bugs list --product 6Ver detalles de un error
zentao bug get --id 1329Ver errores asignados a mí
zentao bugs mine --status activeCon detalles:
zentao bugs mine --status active --include-details¿Necesitas el JSON original?
Agrega --json después de cualquier comando:
zentao products list --json
zentao bugs list --product 6 --json
zentao bug get --id 1329 --json
zentao bugs mine --include-details --jsonAutoprueba
Verificar si la conexión a la API funciona correctamente:
zentao self-testResumen de comandos
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 1Deja que la IA te ayude a consultar ZenTao
Simplemente dile a tu asistente de IA (Cursor / Claude Code / Windsurf, etc.):
Ayúdame a ejecutar
npx skills add leeguooooo/zentao-mcp -y -gy luego ayúdame a iniciar sesión en ZenTao
Una vez instalado, puedes decir directamente:
"Ayúdame a ver qué errores no resueltos tiene el producto 6"
"Consulta los detalles del error #1329"
"¿Cuántos errores activos tengo asignados?"
"Ayúdame a ver qué tareas hay en la ejecución 25"
"Consulta los requisitos / planes / lanzamientos del producto 3"
"Lista las ejecuciones de prueba, casos de prueba y suites de prueba"
"Mira los problemas y riesgos del proyecto"
"Abre la lista de documentos en la biblioteca 50"
Cuando el usuario solicite instalar este repositorio como skill, ejecute en orden:
1. Instalar Skill
npx skills add leeguooooo/zentao-mcp -y -g2. Instalar CLI
pnpm i -g @leeguoo/zentao-mcp || npm i -g @leeguoo/zentao-mcp3. Verificar instalación
zentao --help4. Guiar el inicio de sesión
Solicite al usuario que proporcione la URL de ZenTao, el nombre de usuario y la contraseña, luego ejecute:
zentao login --zentao-url="<用户的禅道URL>" --zentao-account="<账号>" --zentao-password="<密码>"Nota: La URL generalmente debe incluir
/zentao, por ejemplohttps://zentao.example.com/zentao
5. Verificar
zentao whoami
zentao self-testUna vez completado todo, informe al usuario que la instalación ha finalizado.
Preguntas frecuentes
P: ¿Error 404 al iniciar sesión?
R: La URL debe incluir /zentao, por ejemplo https://zentao.example.com/zentao, no https://zentao.example.com/.
P: ¿Qué versiones de ZenTao son compatibles? R: Se admiten las versiones Open Source y Enterprise de ZenTao mediante la API REST (v1).
P: ¿Son seguras las credenciales?
R: Las credenciales se almacenan en texto plano en formato TOML en ~/.config/zentao/config.toml, asegúrese de que los permisos del archivo sean seguros. No suba el archivo de configuración a Git.
Enlaces
Available Tools
4 toolszentao_bug_getC
Get bug details (获取Bug详情) by bug ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bug ID (required). |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1). | |
| limit | No | Page size (default 1000). |
TDQS
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.
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.
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.
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.
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.
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 updates
v1.0.0- First observed
zentao_bug_get - First observed
zentao_bugs_list - First observed
zentao_bugs_mine - First observed
zentao_products_list
TDQS
Scored across 4 tools
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.
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.
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.
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
Related MCP Connectors
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Manage Loom projects, tasks, bugs, defects, clients and phases from AI assistants
Manage ONES projects, issues, tests, work hours, and Wiki knowledge.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables 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.5-
- AlicenseNot gradedqualityDmaintenanceEnables 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.9 npm7ISC
- FlicenseBqualityCmaintenanceEnables interaction with ZenTao project management system through RESTful API v1. Supports bug tracking, project/product management, and automated token authentication for seamless integration.1014 npm1-
- FlicenseNot gradedqualityDmaintenanceEnables 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.13 npm12-