Skip to main content
Glama
dannyvan

@dannyvan/zentao-mcp

by dannyvan

关闭 Bug(状态流转)

zentao_close_bug
Destructive

Close a resolved bug in ZenTao after preview; confirmation needed to execute.

Instructions

关闭一个已解决的 Bug。高风险:默认预览,confirm=true 才执行。 Args: id, comment?, confirm(默认 false)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesBug ID
commentNo备注
confirmNofalse=仅预览;true=真正提交

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

The description discloses the two-phase preview/commit pattern ('默认预览,confirm=true 才执行') and warns of high risk ('高风险'), which adds substantial value beyond the destructiveHint=true annotation. This aligns with the annotation and explains the critical safety gate an agent must respect. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight: a one-line purpose, a risk warning, and a compact args listing. The risk and confirm behavior are front-loaded ahead of the redundant Args line. The Args line duplicates the schema but is short enough not to be wasteful.

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 destructive mutation with no output schema and no post-condition details, the description covers the critical confirm gate and risk profile well. It does not, however, describe what the response looks like, whether the state change is reversible, or what happens after closing – gaps an agent might need for a state-transition operation.

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 coverage is 100%, so all three parameters are already documented. The description's Args line largely restates the schema, but it does add semantic value by explaining confirm's meaning ('confirm=true 才执行' ties the flag to actual execution) and marks comment as optional. Baseline 3 is appropriate since the schema carries most of the load.

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 states a specific verb and resource ('关闭一个已解决的 Bug' – close a resolved Bug), which is clear about the action and target. It adds the nuance that the bug must be resolved first, helping distinguish from state-transition siblings like resolve, activate, and confirm. It doesn't explicitly contrast against siblings, so it loses a point, but the purpose is unambiguous.

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

Usage Guidelines3/5

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

The precondition '已解决的' (resolved) implicitly tells the agent this tool is only appropriate after a bug has been resolved, which is genuine usage guidance. However, it never mentions when NOT to use it or names alternatives such as confirm_bug or resolve_bug, leaving sibling differentiation to inference.

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