Which integrations are available for this server?

Allows running Jest tests via npx jest with JSON output parsing. Allows running pytest tests with bounded execution, single test targeting, and coverage summary.

How do I use mcp-test-runner?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-test-runner run pytest on tests/ and show coverage" 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.

mcp-test-runner

by LovRanRan

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

mcp-test-runner

MCP server for deterministic local test execution and normalized test result reporting.

mcp-test-runner is the verification layer for codebase onboarding agents. It exposes focused MCP tools for running pytest and Jest, parsing test output, and summarizing coverage so downstream agents can mark claims as verified, unverified, or contradicted by real execution.

Codebase Onboarding Stack

mcp-test-runner is the verification layer in a three-server MCP tool stack for Project 6 wayfinder, a codebase onboarding agent.

mcp-repo-mapper maps repository structure, languages, entry points, framework evidence, and Python dependency edges.
mcp-ast-explorer provides symbol-grounded Python definition, signature, reference, call-chain, and class-hierarchy lookups.
mcp-test-runner runs local pytest/Jest checks and coverage summaries so agent claims can be verified against execution.

In wayfinder, this server turns high-risk code understanding claims into verified, unverified, or contradicted evidence from real test execution.

Related MCP server: MCP Testing Assistant

Status

This repository is a Python-first v1 MCP test runner. It supports bounded pytest execution, Jest command execution, single-test targeting, pytest coverage summaries, and normalized pytest/Jest JSON parsing.

The server does not use an LLM. Test results come from subprocess execution and structured parser output.

Tools

Tool	Purpose
`health()`	Returns `ok` for smoke checks.
`run_pytest(path, test_filter?, timeout_seconds?, cpu_seconds?, memory_mb?)`	Run pytest in a bounded working directory and return raw command output.
`run_jest(path, test_filter?, timeout_seconds?, cpu_seconds?, memory_mb?)`	Run Jest through `npx jest` and return raw command output.
`run_single_test(path, test_id, framework?, timeout_seconds?, cpu_seconds?, memory_mb?)`	Run one pytest node id or one Jest test-name pattern.
`parse_test_output(stdout, framework)`	Normalize test runner JSON output.
`get_coverage_summary(path, framework?, timeout_seconds?, cpu_seconds?, memory_mb?)`	Return pytest-cov JSON coverage totals.

Supported Scope

Python 3.11+ package.
FastMCP 2.x server.
pytest execution with JSON report output via pytest-json-report.
Jest command execution via npx jest --json --outputFile.
pytest and Jest JSON normalization into one TestRunResult schema.
Single pytest node id execution and Jest test-name targeting.
pytest-cov coverage summary from .coverage.json.
Subprocess timeout plus POSIX resource.setrlimit CPU / memory caps.

Current Limitations

v1 does not use Docker. It uses cwd validation, subprocess timeouts, and POSIX resource limits.
Resource limits require a POSIX platform that supports resource.setrlimit.
Jest execution expects Node.js plus project-local or npx-resolvable Jest.
Jest single-test targeting uses --testNamePattern; it does not parse Jest file-specific node ids.
Coverage summary is pytest-only in v1.
Tools return raw command output for execution; call parse_test_output to normalize framework JSON.

Local Development

Install dependencies:

uv sync --extra dev

The PyPI distribution name is lovranran-mcp-test-runner because mcp-test-runner is already taken on PyPI. The installed console script remains mcp-test-runner.

Run the MCP server:

uv run mcp-test-runner

Run verification:

uv run ruff check .
uv run mypy
uv run pytest

License

MIT

Available Tools

6 tools

get_coverage_summaryD

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`framework`	No	pytest
`memory_mb`	No
`cpu_seconds`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`framework`	Yes
`report_path`	No
`total_lines`	Yes
`covered_lines`	Yes
`percent_covered`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

healthD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

parse_test_outputD

ParametersJSON Schema

Name	Required	Description	Default
`stdout`	Yes
`framework`	No		pytest

Output Schema

ParametersJSON Schema

Name	Required	Description
`failed`	No
`passed`	No
`skipped`	No
`failures`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_jestD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`memory_mb`	No
`cpu_seconds`	No
`test_filter`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`stderr`	Yes
`stdout`	Yes
`exit_code`	Yes
`timed_out`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_pytestD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`memory_mb`	No
`cpu_seconds`	No
`test_filter`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`stderr`	Yes
`stdout`	Yes
`exit_code`	Yes
`timed_out`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_single_testD

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`test_id`	Yes
`framework`	No	pytest
`memory_mb`	No
`cpu_seconds`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`stderr`	Yes
`stdout`	Yes
`exit_code`	Yes
`timed_out`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jul 29, 2026
- First observedget_coverage_summary
- First observedhealth
- First observedparse_test_output
- First observedrun_jest
- First observedrun_pytest
- First observedrun_single_test

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.9/5.0

Scored 2026-07-29 12:35 across 6 tools

Disambiguation4/5

The tool names clearly differentiate between different testing frameworks (pytest vs jest), single test execution, output parsing, coverage, and health. Without descriptions, there is slight potential confusion between run_pytest and run_single_test, but names are sufficiently distinct.

Naming Consistency3/5

Three tools use the 'run_' prefix (run_pytest, run_jest, run_single_test), but parse_test_output, get_coverage_summary, and health deviate. The pattern is mixed but still readable and not chaotic.

Tool Count5/5

With 6 tools, the server covers essential test runner operations: running tests by framework, running a single test, parsing output, coverage, and health check. Each tool serves a distinct purpose without unnecessary bloat.

Completeness4/5

The tool set covers core testing workflows: running tests (multiple frameworks), analyzing results (parse output, coverage), and health monitoring. Minor gaps like a combined test runner or report generation exist but do not hinder basic usage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
meok-mcp-test-mcp
io.github.CSOAI-ORG
MEOK MCP Test MCP — golden-file + schema-drift + tool-failure tests for any MCP server. Drop-in
Testing & QA Tools Developer Tools
2
Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2
UI Verify A
io.github.igrlk
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
Testing & QA Tools CI/CD & DevOps
9118

Related MCP Servers

MCP Pytest Server
Testing & QA Tools Developer Tools
kieranlal
F
license
Not graded
quality
D
maintenance
A Node.js server that integrates with pytest to facilitate the ModelContextProtocol (MCP) service tools, enabling test execution recording and environment tracking.
Updated 2 years ago (2025-01-19 17:37 UTC)
6
-
MCP Testing Assistant
Testing & QA Tools CI/CD & DevOps Developer Tools
mcpassistant
-
license
Not graded
quality
Not graded
maintenance
Enables automated testing and coverage reporting for MCP services with test execution, file generation, and mock service creation. Provides comprehensive testing infrastructure including Jest integration, coverage reports, and health checks for the MCP ecosystem.
Updated a year ago (2025-09-02 05:59 UTC)
-
Chisel
Developer Tools CI/CD & DevOps Code Analysis
IronAdamant
A
license
Not graded
quality
B
maintenance
MCP server for test impact analysis and code intelligence. Maps tests to code and git history to determine impacted tests, risk scores, and ownership for AI coding agents.
Updated 2 months ago (2026-07-09 02:15 UTC)
2
MIT
Testing MCP
Testing & QA Tools Code Analysis
shalonjovan
A
license
Not graded
quality
B
maintenance
A universal AI-powered testing server built on the Model Context Protocol (MCP). Allows AI agents to inspect, execute, test, monitor, debug, and report on software projects.
Updated 2 months ago (2026-07-09 05:11 UTC)
3
GNU Lesser General Public v2.1 only