Run complete root-cause analysis in one call: classify a change as bugfix or feature, list suspect commits, and get risk score and test impact.
Full RCA in one call: classify -> suspects (bugfix) or blast-radius (feature) -> risk score -> test impact.
Returns the complete structured result. Use the individual tools to drill into specific signals.
| Name | Required | Description | Default |
|---|---|---|---|
| pr | No | ||
| base | No | ||
| head | No | ||
| repo | Yes |
Changes observed during successful MCP inspections.
v0.4.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It reveals a multi-step analytical pipeline and the conditional branching based on bugfix vs feature, plus a 'complete structured result' return. However, it does not disclose whether the operation is read-only, potentially expensive, or what happens when optional params like pr/base/head are absent. These are meaningful 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?
Two short, dense paragraphs with a front-loaded purpose and no filler; every sentence contributes purpose, pipeline, or routing to siblings. Nothing is wasted.
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?
The tool has 4 params, no output schema, and no annotations. The description communicates the overall workflow and result shape at a high level, but leaves out how the optional parameters combine, what a 'complete structured result' actually contains in detail, and any constraints or prerequisites. Sufficient as a summary, not as full operational guidance.
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 0% and the description never explains how repo, pr, base, or head are used. The param names are somewhat self-evident in a git context, but the description adds no mapping to its pipeline stages, so it cannot compensate for the lack of schema descriptions.
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 opens with 'Full RCA in one call' and maps the internal pipeline (classify -> suspects/blast-radius -> risk score -> test impact), giving a specific verb-resource scope. It clearly differentiates itself from sibling tools by framing them as drill-downs, so an agent can tell this composite tool apart.
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?
It explicitly states when to use this tool ('Full RCA in one call') and when not: 'Use the individual tools to drill into specific signals.' That is an explicit alternative and exclusion, even though it does not enumerate each sibling by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.