LabscoMCP early access ↗
that1guy15MCP SERVER

Tox Testing

Run a Python project's tox suite from the conversation — everything, one group, one file, one directory, or a single test case.

by that1guy15 ↗Automated Testing & QACommunity

LABSCO SUMMARY

One tool, four scopes, and the timeout you will be glad of.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

One command — npx -y github:that1guy15/tox-testing