siftwise
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SIFTWISE_REPO | No | Optional: owner/name of the repository in siftwise (default: from the git origin remote) | |
| SIFTWISE_SERVER | No | URL of your siftwise server (default: http://localhost:8000) | |
| SIFTWISE_BASE_REF | No | Optional: base branch to diff against (default: origin/HEAD, else main) | |
| SIFTWISE_API_TOKEN | Yes | The siftwise server's API token (the server's SIFTWISE_API_TOKEN) | |
| SIFTWISE_REPO_PATH | No | Optional: path to the repository, when the client starts the server outside it |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| select_testsA | Call this before running tests after changing code. It returns the command that runs only the tests your change (committed and uncommitted) can affect, with a reason per test. Run that command instead of the full test suite. If mode is "full", run the project's full test suite; if the command is empty in selective mode, no tests are affected. |
| triage_failureA | 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. |
| explainA | Call this to understand one test: its recent results, whether it is flaky or broken on main, and why siftwise would or wouldn't select it for your current change. Use it when a selection or a triage verdict surprises you, before overriding it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools serve clearly distinct workflow stages: selecting affected tests before a run, triaging failing tests afterward, and explaining one test in detail when needed. The descriptions explicitly state when to call each, so an agent should not confuse them.
select_tests and triage_failure follow a clear verb_noun pattern, while explain is a bare verb. The deviation is minor and readable, but it prevents a perfect consistency score.
Three tools is a minimal but well-scoped set for the server's test-selection and triage purpose. Each tool earns its place, though the surface is at the low end of what feels comfortably complete.
The tools cover the core lifecycle: selecting tests, triaging failures, and explaining individual test behavior. Minor gaps exist around discovering/configuring test inventory or reporting outcomes, but the main workflow has no dead ends.