The scope argument is the whole design: run everything to find what broke, rerun the single case while you fix it, then run everything again to confirm nothing else moved — a loop the README spells out as a custom instruction worth pasting into your client. `TOX_TIMEOUT` matters more than it looks: without a ceiling, one hung integration test takes the session with it.
A single-tool MCP server that executes tox in a Python project, running its pytest suite at whatever scope you name. The point is the narrowing: after a full run fails, the same tool reruns just the failing case, which is the loop debugging actually takes.
- The whole suite run, or one named test group — `clients`, `api`, `auth`, `uploads` or `routes` — with `mode` set to `all` — `run_tox_tests`
- A single file run by passing `mode` as `file` with `testFile`, or one test case by adding `testCase`
- Every test under a directory run with `mode` set to `directory`
- A time limit on the run, so a hung test process is terminated rather than blocking the session
No account and no key — it runs tox on your machine. `TOX_APP_DIR` is required and must point at the directory containing `tox.ini`, since that is where tox is invoked from. `TOX_TIMEOUT` sets the maximum seconds for a run and defaults to 600. The npm package name is `tox-testing` (0.1.0) and it is marked private, so build from a clone with `npm install` and `npm run build`, then point your client at the built `index.js`. Running tests means running the project's code, so point it at a project you trust.
One command — npx -y github:that1guy15/tox-testing