vacuous-tests-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@vacuous-tests-mcp scan ./src for vacuous tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
vacuous-tests-mcp
An MCP server that finds tests which pass no matter what the code does.
A vacuous test is worse than a missing one. A missing test is visibly missing. A vacuous test sits in the suite, runs green, counts in the total, and gets quoted as evidence that a behaviour is covered — while checking nothing. It is coverage that is invisibly absent, and it survives exactly the situations tests exist to catch.
They are easy to write by accident and hard to spot by reading, because a vacuous test and a real one often look nearly identical.
The case this was built from
A Rust file, 6,764 lines, in a project whose test suite was already under regular manual audit. Two tests in it:
// flagged
const SRC: &str = include_str!("lib.rs");
assert!(SRC.contains("pub sas_verified: bool,"), "the field must be exposed");// not flagged
const SRC: &str = include_str!("lib.rs");
let prod = SRC.split_once("\n#[cfg(test)]\nmod tests {").expect("test module").0;
assert!(prod.contains("InviterSecrets::create_for_group("), "production never calls it");Both embed the file's own source. The first asserts on SRC directly — and SRC contains the
test itself, including the very string being searched for. It is true by construction: delete
the production code it claims to guard and it stays green. The second cuts the test module off
first and asserts on the production slice only, so it fails when the production code changes.
That one is a real gate.
Scanning that file reports one finding, at the right line, and leaves the other four
include_str! sites alone. The scanner follows the binding rather than pattern-matching on
include_str!, which is what separates the two cases.
Related MCP server: openhonest-umbra
Rules
Rule | Severity | What it catches |
| high | The test embeds its own source and asserts a literal appears in it. The literal is in the assertion, so it can never fail. |
| high | No assertion of any kind. Only a panic or throw can fail the test, so wrong-but-quiet behaviour passes. |
| high |
|
| high | Nothing in the body to fail. |
| info |
|
Languages
Language | Method | Accuracy |
Python |
| Exact |
Rust | brace-matching scanner over the source text | Heuristic |
JavaScript / TypeScript | brace-matching scanner over the source text | Heuristic |
The Rust and JS scanners mask string literals and comments before matching, so a { inside a
string or a commented-out assertion cannot mislead them. They are tuned to miss a case rather
than invent one: a false positive costs more than a false negative here, because the first
wrong answer teaches people to ignore the output.
Treat every finding as a question to check, not a verdict. Each one names a file and a line, so confirming it takes seconds.
Install
Not on PyPI yet — install from source:
git clone https://github.com/zegroged/vacuous-tests-mcp
cd vacuous-tests-mcp
pip install .That puts a vacuous-tests-mcp command on your PATH.
Use it from an MCP client
Add to your client's MCP configuration:
{
"mcpServers": {
"vacuous-tests": {
"command": "vacuous-tests-mcp"
}
}
}For Claude Code:
claude mcp add vacuous-tests -- vacuous-tests-mcpThen ask it to scan something:
Scan ./src for tests that can't fail.
Tools
scan_tests(path, include_skipped=True, max_findings=100)
Walk a file or directory and report tests that cannot fail. Build and dependency directories
(target, node_modules, .venv, …) are skipped. Findings come back highest severity first,
each with a path, line, test name, rule and snippet.
list_rules()
Every rule with a description, so a model can decide what to ask for.
explain_rule(rule)
What one rule detects and how the finding is usually resolved.
The server only reads. It does not write files, does not execute the code it scans, and does not look outside the path it was given.
Development
pip install -e ".[dev]"
pytestThe suite covers each rule in each language, and — more importantly — checks that a normal test sitting next to a vacuous one is not reported. There is also an end-to-end test that starts the server as a subprocess and drives it through a real MCP handshake, so the protocol layer is covered rather than assumed.
Limitations
Rust and JS/TS detection is textual, not a parse. Macro-generated tests, unusual formatting and heavily nested closures can be missed.
no-assertionsdoes not know that a test may exist purely to prove something does not panic. Such a test is a true positive by the rule and a false positive by intent; say so with an explicit assertion and it goes quiet.Only the languages in the table above are scanned. Other files are ignored, not guessed at.
License
MIT
Available Tools
3 toolsexplain_ruleA
Explain one rule: what it detects and how the finding is usually resolved.
Args:
rule: A rule id as returned by list_rules or by a finding, for example
self-referential-source.
Inputs: rule (required). Returns: object
list_rulesA
List every rule the scanner applies, with a one-paragraph description of each.
Inputs: no named parameters. Returns: object
scan_testsA
Scan a file or directory for tests that cannot fail.
Reports tests that pass regardless of the behaviour of the code they claim to cover: assertions that are true by construction, tests with no assertion at all, empty bodies, and tests that are skipped while still appearing in the suite.
Python is analysed with the ast module and is exact. Rust and JavaScript/TypeScript
use a brace-matching text scanner, which is a heuristic tuned to miss cases rather than
invent them. Every finding carries a file and line so it can be checked directly.
Args:
path: File or directory to scan. Build and dependency directories (target,
node_modules, .venv, ...) are skipped automatically.
include_skipped: Include tests marked skipped or ignored. These always run green
because they do not run at all, but they are usually deliberate, so they are
reported at info severity.
max_findings: Cap on returned findings. The summary always counts every finding,
including any beyond the cap.
Inputs: path (required), max_findings, include_skipped. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 3 tools
Each tool has a distinct purpose: listing available rules, explaining a specific rule, and scanning tests for vacuous assertions. There is no overlap between scan_tests and the two rule-related tools, and list_rules/explain_rule are clearly separated by verb (list vs. explain).
All tools follow a consistent snake_case verb_noun pattern: list_rules, explain_rule, scan_tests. The naming is predictable and aligns perfectly with the tool's action.
With 3 tools, the server is well-scoped for its purpose—a test scanner with rule documentation. Each tool earns its place, and the count falls squarely within the typical 3-15 range for a focused server.
The tool surface fully covers the intended workflow: discover rules, understand a rule, and run the scanner. There are no obvious gaps—the scanner's options are handled via arguments rather than requiring additional tools, and the rule lifecycle (list/explain) is complete for a read-only server.
Maintenance
Related MCP Connectors
Detects database migration table locks, terraform cost leaks, and OWASP API flaws.
Flaky test detection, root cause analysis, and fix suggestions for development teams.
Generates unit tests for Python code with coverage before/after reports and concrete edge cases.
Change-aware CI validation and affected-test guidance for coding agents.
Related MCP Servers
AlicenseAqualityBmaintenanceOpen-source MCP server and CLI. It maps every function to the tests that call it, ranks untested risk, and uses mutation proof to show a test catches a break. Local, MIT.19128 npm20MIT
openhonest-umbraofficial
AlicenseAqualityAmaintenanceAudits a module against its test suite and reports the cases the tests are structurally unable to see, then proves each gap with a real failing test rather than a warning. Covers Python, TypeScript, JavaScript, Java, Rust and Go.43Apache 2.0- AlicenseNot gradedqualityCmaintenanceGenerates complete runnable adversarial test suites for your code, predicting the bugs they expose with exact code evidence, across multiple languages and test frameworks.MIT

Nemesis-MCPofficial
AlicenseAqualityBmaintenanceChecks mocks, stubs, and spies against current production code to detect stale or mismatched test doubles without running any tests.3MIT