Show configured reviewers, their families, and the quality gates they serve. Use this to verify reviewer assignments and gate coverage.
Show the configured reviewers, their families and which gates they serve.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It tells the agent that the tool shows configuration data and is therefore read-only in nature, but it does not explicitly state that no changes occur, nor does it provide details like response format or reliance on configuration. This is minimally adequate for a zero-parameter list tool.
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 a single concise sentence with no filler, and it front-loads the primary action ('Show') followed by the three pieces of content (reviewers, families, gates). Every word earns its place.
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 has no parameters, no annotations, and no output schema, the description sufficiently explains the return value's content (reviewers, families, gates). It is slightly vague about what 'families' means and whether additional configuration context is included, but it is adequate for a simple list command.
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 tool has no parameters, and the schema confirms this, so there are no parameter semantics to clarify. The description adds value by stating what information is displayed, meeting the baseline for a parameterless tool.
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 uses a specific verb ('Show') and a specific resource ('configured reviewers'), and goes beyond a simple name restatement by enumerating what is displayed: their families and the gates they serve. This distinguishes it from siblings like ddflow_reviewers_detect, which implies detection rather than listing configured data.
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 implies the tool is a read-only listing operation, so an agent can infer it is for inspecting configured reviewers. However, it provides no explicit when-to-use guidance, no conditions, and no mention of alternatives such as ddflow_reviewers_detect or other reviewer-related commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.