siftwise

triage_failure

Classify failing tests as new regressions, pre-existing failures, flaky, or unknown before fixing them, using JUnit XML reports or failing test IDs to decide what to address.

Instructions

Call this when tests fail, before trying to fix them. For each failing test it says whether your change caused it (new_regression: fix these), it was already failing on main (pre_existing: not yours), it is flaky (flaky: re-run it, don't fix it), or siftwise can't tell (unknown). Pass the JUnit XML report paths from the test run, or the failing test IDs (pytest node IDs like tests/test_x.py::test_y work as classname::name, e.g. tests.test_x::test_y) with optional failure messages.

Input Schema

Name	Required	Description
`base`	No	Branch or ref the change is diffed against (default: SIFTWISE_BASE_REF, else the branch origin/HEAD points to, else main).
`variant`	No	CI matrix leg to compare with (e.g. ubuntu-py3.12), if the repo has several.
`failures`	No	Failing tests, if there is no JUnit report: [{"test_id": ..., "message": ...}], message optional.
`repo_path`	No	Absolute path of the repository. Only needed when siftwise says it isn't running in a git repository (default: SIFTWISE_REPO_PATH, CLAUDE_PROJECT_DIR, the client's workspace roots, else the server's working directory).
`junit_paths`	No	JUnit XML reports written by the test run: absolute paths, or relative to the repository root.
`include_uncommitted`	No	Include staged, unstaged and untracked changes in the change.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 28, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the classification taxonomy and semantics, including the honest 'unknown' fallback and the instruction not to fix flaky tests. It stops short of stating that the tool is read-only/analysis-only or explaining what it inspects to make the diff-based determination.

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?

Front-loads the trigger and the verdict taxonomy before any input mechanics, and every clause carries information. It is a single dense paragraph with stacked parentheticals, which is efficient but slightly harder to scan than a short structured form.

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?

An output schema exists, so return values need not be described, and all six parameters are fully documented in the schema. For a read/analyze tool the description covers trigger, verdicts, and input formats well; only the relationship to sibling tools and any side-effect/profile disclosure are absent.

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 the parameters are already documented and the baseline is 3. The description does add genuine value by framing junit_paths versus failures as alternatives ('if there is no JUnit report') and by spelling out the pytest node-ID to classname::name conversion with a worked example.

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?

States a specific verb and resource (triage failing tests) and enumerates the four outcome classes (new_regression, pre_existing, flaky, unknown), which makes the tool's function unmistakable. It never mentions the siblings select_tests or explain, so an agent must infer the boundary rather than being told it.

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

Usage Guidelines4/5

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

Gives a clear trigger ('when tests fail, before trying to fix them') and even prescribes follow-up behavior per verdict class (fix new_regression, ignore pre_existing, re-run flaky, treat unknown as indeterminate). No when-not conditions or named alternatives are offered, so tool selection against select_tests/explain is left to inference.

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

Deploy Server