Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
--dirNoSandbox directory. Only projects inside DIR can be tested; equivalent to passing --dir DIR.
--allow-envNoName of an environment variable to allow through to test processes. Repeatable; equivalent to passing --allow-env NAME for each variable.
--inherit-envNoDisable environment scrubbing and inherit the server's environment; equivalent to passing the --inherit-env flag.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Run a project's tests and get a small structured result instead of a long log. NOTE: this executes the project's code. Typical loop: detect_runner(path) once, run_tests(path), then for failures explain_failure(path, test_id), fix, rerun_failed(path); use flaky_check for tests that fail intermittently and coverage_summary to find untested lines. path is the project root and should be absolute. Every result names the interpreter that was used; if pytest is missing there, pass python= (the project's venv interpreter, or 'uv').

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
detect_runnerA

Detect which test runner a project uses, without running any of its tests.

Looks for pytest (config, conftest.py, dependencies), unittest, jest and vitest (package.json, config files). For each candidate: the evidence, the exact way it would be run, and whether it is ready (pytest importable, node_modules present). For Python it also reports which interpreter would be used (project .venv, else the server's own) and the versions of pytest/coverage found there. Returns test directories too.

path: project root (absolute is safest). python: optional interpreter path, or 'uv'.

run_testsA

Run the tests and return counts plus only the useful details of each failure.

EXECUTES THE PROJECT'S CODE. Result: outcome (passed | failed | no_tests | timeout | crashed | startup_error), summary counts (passed/failed/error/skipped/xfailed/xpassed), failures (id, message, file:line of the innermost project frame, the relevant traceback frames only, trimmed stdout/stderr), collection_errors listed separately from failures (import errors never hide as test failures), the 5 slowest tests, and which interpreter was used. On timeout or crash it names the test that was running. The whole process tree is killed at the timeout.

selector: a file, directory or node id (pytest: tests/test_a.py::TestX::test_y; unittest: dotted name; jest/vitest: file path pattern). Default: everything. timeout: seconds, 1-3600. extra_args: only allow-listed flags, e.g. ["-x"], ["-k", "login"], ["-m", "not slow"], ["--maxfail=3"]; anything else is refused. python: interpreter path or 'uv'. runner: force pytest/unittest/jest/vitest (default: auto-detected, see detect_runner).

rerun_failedA

Re-run only the tests that failed or errored in the last run_tests/rerun_failed for this project (same server session). Returns the same structure as run_tests, plus how many ids were rerun (at most 100). The failure list is replaced by what still fails.

list_testsA

List the tests without running them (collect-only). Returns ids (max 500) and any collection errors (import errors in test modules or conftest.py), reported separately.

filter: pytest -k expression / unittest name pattern / substring of a jest or vitest file name. For jest and vitest only test FILES can be listed. Use the ids as run_tests selectors and as flaky_check / explain_failure test_id.

flaky_checkA

Run ONE test n times (2-20, each a fresh process) and report the pass/fail pattern.

Returns pattern like "PPFPP" (P pass, F fail, S skipped, T timeout), counts, a verdict (flaky | stable_pass | consistently_failing | inconclusive), the failure rate, and the first failure's details. Worst case it takes n x timeout seconds. A test that is only flaky when run with others (ordering, parallelism, shared state) can pass here; check that with run_tests on the surrounding file.

test_id: exact id from run_tests/list_tests (pytest: path::Class::test[param]; jest/vitest: path/file.test.js::full test name; unittest: dotted name).

explain_failureB

Full detail for one failing test: re-runs just that test with the long traceback and (for pytest) --showlocals, and returns the complete traceback text (capped at 20k chars) with local variable values, the assertion message, and captured stdout/stderr. If the test passes when run alone, it says so (flaky or order-dependent).

coverage_summaryA

Run the Python tests under coverage.py and report per-file percent and the uncovered line ranges (e.g. "12-15, 20"). Needs coverage installed in the project's interpreter (the error says which). Data goes to a temp dir; nothing is written into the project.

files: optional list of paths or globs relative to the project (src/app.py, src/*.py) to report; default is the 30 least-covered project files plus the total percent. selector: run only part of the suite. Python projects only.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 7 tools

Disambiguation4/5

The tools mostly have distinct purposes: detection, listing, running, coverage, rerunning failures, flaky checks, and failure explanation. There is some overlap among run_tests, rerun_failed, flaky_check, and explain_failure because all execute tests, but the descriptions make their boundaries reasonably clear.

Naming Consistency4/5

Most names follow a verb_noun pattern (detect_runner, run_tests, rerun_failed, list_tests, explain_failure), and all use snake_case consistently. coverage_summary and flaky_check are noun-phrase deviations, but they remain readable and predictable.

Tool Count5/5

Seven tools is well-scoped for a test-runner MCP server. Each tool covers a distinct part of the test workflow without obvious redundancy.

Completeness4/5

The surface covers detection, listing, running, rerunning failures, coverage, flaky detection, and failure explanation, which is strong lifecycle coverage. Minor gaps include coverage being Python-only and no equivalent coverage or profiling support for JavaScript runners.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues