Test Runner MCP
The Test Runner MCP server provides a unified interface for executing and parsing test results across multiple testing frameworks:
Run tests for multiple frameworks: Bats, Pytest, Flutter, Jest, Go, Rust, and generic commands
Capture and parse test results into structured output while preserving raw output for debugging
Configure execution parameters including working directories, environment variables, and timeouts (default: 300000ms)
Security features to validate and sanitize commands, with configurable overrides for specific elevated permissions
Enhanced framework support such as automatic environment setup for Flutter and detailed error handling for Rust (RUST_BACKTRACE=1)
CI/CD integration with flexible automation and pipeline support for arbitrary command execution
Integrates with Dependabot for automated dependency updates
Allows running and parsing Flutter tests, with enhanced support including environment setup, error handling, and detailed output processing
Integrates with GitHub Actions for continuous integration, including automated testing on Node.js 18.x and 20.x, test results uploaded as artifacts
Allows running and parsing Jest (JavaScript Testing Framework) tests and processing their outputs
Allows running and parsing Pytest (Python Testing Framework) tests and processing their outputs
Click on "Install 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., "@Test Runner MCPrun pytest on my tests directory and save results to reports"
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.
Test Runner MCP
A Model Context Protocol (MCP) server for running and parsing test results from multiple testing frameworks. This server provides a unified interface for executing tests and processing their outputs, supporting:
Bats (Bash Automated Testing System)
Pytest (Python Testing Framework)
Flutter Tests
Jest (JavaScript Testing Framework)
Go Tests
Rust Tests (Cargo test)
Generic (for arbitrary command execution)
Installation
npm install test-runner-mcpRelated MCP server: Tailscale MCP Server
Prerequisites
The following test frameworks need to be installed for their respective test types:
Bats:
apt-get install batsorbrew install batsPytest:
pip install pytestFlutter: Follow Flutter installation guide
Jest:
npm install --save-dev jestGo: Follow Go installation guide
Rust: Follow Rust installation guide
Usage
Configuration
Add the test-runner to your MCP settings (e.g., in claude_desktop_config.json or cline_mcp_settings.json):
{
"mcpServers": {
"test-runner": {
"command": "node",
"args": ["/path/to/test-runner-mcp/build/index.js"],
"env": {
"NODE_PATH": "/path/to/test-runner-mcp/node_modules",
// Flutter-specific environment (required for Flutter tests)
"FLUTTER_ROOT": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter",
"PUB_CACHE": "/Users/username/.pub-cache",
"PATH": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter/bin:/usr/local/bin:/usr/bin:/bin"
}
}
}
}Note: For Flutter tests, ensure you replace:
/opt/homebrew/Caskroom/flutter/3.27.2/flutterwith your actual Flutter installation path/Users/username/.pub-cachewith your actual pub cache pathUpdate PATH to include your system's actual paths
You can find these values by running:
# Get Flutter root
flutter --version
# Get pub cache path
echo $PUB_CACHE # or default to $HOME/.pub-cache
# Get Flutter binary path
which flutterRunning Tests
Use the run_tests tool with the following parameters:
{
"command": "test command to execute",
"workingDir": "working directory for test execution",
"framework": "bats|pytest|flutter|jest|go|rust|generic",
"outputDir": "directory for test results",
"timeout": "test execution timeout in milliseconds (default: 300000)",
"env": "optional environment variables",
"securityOptions": "optional security options for command execution"
}Example for each framework:
// Bats
{
"command": "bats test/*.bats",
"workingDir": "/path/to/project",
"framework": "bats",
"outputDir": "test_reports"
}
// Pytest
{
"command": "pytest test_file.py -v",
"workingDir": "/path/to/project",
"framework": "pytest",
"outputDir": "test_reports"
}
// Flutter
{
"command": "flutter test test/widget_test.dart",
"workingDir": "/path/to/project",
"framework": "flutter",
"outputDir": "test_reports",
"FLUTTER_ROOT": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter",
"PUB_CACHE": "/Users/username/.pub-cache",
"PATH": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter/bin:/usr/local/bin:/usr/bin:/bin"
}
// Jest
{
"command": "jest test/*.test.js",
"workingDir": "/path/to/project",
"framework": "jest",
"outputDir": "test_reports"
}
// Go
{
"command": "go test ./...",
"workingDir": "/path/to/project",
"framework": "go",
"outputDir": "test_reports"
}
// Rust
{
"command": "cargo test",
"workingDir": "/path/to/project",
"framework": "rust",
"outputDir": "test_reports"
}
// Generic (for arbitrary commands, CI/CD tools, etc.)
{
"command": "act -j build",
"workingDir": "/path/to/project",
"framework": "generic",
"outputDir": "test_reports"
}
// Generic with security overrides
{
"command": "sudo docker-compose -f docker-compose.test.yml up",
"workingDir": "/path/to/project",
"framework": "generic",
"outputDir": "test_reports",
"securityOptions": {
"allowSudo": true
}
}Security Features
The test-runner includes built-in security features to prevent execution of potentially harmful commands, particularly for the generic framework:
Command Validation
Blocks
sudoandsuby defaultPrevents dangerous commands like
rm -rf /Blocks file system write operations outside of safe locations
Environment Variable Sanitization
Filters out potentially dangerous environment variables
Prevents overriding critical system variables
Ensures safe path handling
Configurable Security
Override security restrictions when necessary via
securityOptionsFine-grained control over security features
Default safe settings for standard test usage
Security options you can configure:
{
"securityOptions": {
"allowSudo": false, // Allow sudo commands
"allowSu": false, // Allow su commands
"allowShellExpansion": true, // Allow shell expansion like $() or backticks
"allowPipeToFile": false // Allow pipe to file operations (> or >>)
}
}Flutter Test Support
The test runner includes enhanced support for Flutter tests:
Environment Setup
Automatic Flutter environment configuration
PATH and PUB_CACHE setup
Flutter installation verification
Error Handling
Stack trace collection
Assertion error handling
Exception capture
Test failure detection
Output Processing
Complete test output capture
Stack trace preservation
Detailed error reporting
Raw output preservation
Rust Test Support
The test runner provides specific support for Rust's cargo test:
Environment Setup
Automatically sets RUST_BACKTRACE=1 for better error messages
Output Parsing
Parses individual test results
Captures detailed error messages for failed tests
Identifies ignored tests
Extracts summary information
Generic Test Support
For CI/CD pipelines, GitHub Actions via act, or any other command execution, the generic framework provides:
Automatic Output Analysis
Attempts to segment output into logical blocks
Identifies section headers
Detects pass/fail indicators
Provides reasonable output structure even for unknown formats
Flexible Integration
Works with arbitrary shell commands
No specific format requirements
Perfect for integration with tools like
act, Docker, and custom scripts
Security Features
Command validation to prevent harmful operations
Can be configured to allow specific elevated permissions when necessary
Output Format
The test runner produces structured output while preserving complete test output:
interface TestResult {
name: string;
passed: boolean;
output: string[];
rawOutput?: string; // Complete unprocessed output
}
interface TestSummary {
total: number;
passed: number;
failed: number;
duration?: number;
}
interface ParsedResults {
framework: string;
tests: TestResult[];
summary: TestSummary;
rawOutput: string; // Complete command output
}Results are saved in the specified output directory:
test_output.log: Raw test outputtest_errors.log: Error messages if anytest_results.json: Structured test resultssummary.txt: Human-readable summary
Development
Setup
Clone the repository
Install dependencies:
npm installBuild the project:
npm run build
Running Tests
npm testThe test suite includes tests for all supported frameworks and verifies both successful and failed test scenarios.
CI/CD
The project uses GitHub Actions for continuous integration:
Automated testing on Node.js 18.x and 20.x
Test results uploaded as artifacts
Dependabot configured for automated dependency updates
Contributing
Fork the repository
Create your feature branch
Commit your changes
Push to the branch
Create a Pull Request
License
This project is licensed under the MIT License - see the LICENSE file for details.
Available Tools
1 toolrun_testsC
Run tests and capture output
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Test command to execute (e.g., "bats tests/*.bats") | |
| env | No | Environment variables for test execution | |
| framework | Yes | Testing framework being used | |
| outputDir | No | Directory to store test results | |
| securityOptions | No | Security options for command execution | |
| timeout | No | Test execution timeout in milliseconds (default: 300000) | |
| workingDir | Yes | Working directory for test execution |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'capture output' but doesn't describe output format, error handling, side effects, or security implications. The description doesn't contradict annotations (none exist), but fails to disclose important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loaded with the core action and outcome. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters, nested objects, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, security considerations, or typical usage patterns that would help an agent understand this execution tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond the schema's comprehensive coverage, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run tests and capture output' clearly states the action (run tests) and outcome (capture output), but lacks specificity about what types of tests or how they're executed. It doesn't distinguish from siblings (none exist), but remains somewhat vague about scope and implementation details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or typical scenarios. With no sibling tools mentioned, differentiation isn't needed, but there's still no context about appropriate use cases or limitations.
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. Dates show when Glama detected each change.
1 tool update
v1.0.0- First observed
run_tests
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as running tests and capturing output, making it distinct by default.
The single tool name 'run_tests' follows a clear verb_noun pattern, which is consistent within this minimal set. There are no other tools to compare against, so no inconsistency can arise.
A single tool is generally too few for most server purposes, as it limits functionality and flexibility. For a test runner, one tool might cover basic execution but lacks operations like listing tests, filtering, or managing test suites, making it feel thin and under-scoped.
The tool surface is severely incomplete for a test runner domain. It only provides execution without supporting operations such as listing available tests, retrieving results, configuring test runs, or handling test environments, leading to significant gaps that could cause agent failures.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.
Flaky test detection, root cause analysis, and fix suggestions for development teams.
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceFacilitates isolated code execution within Docker containers, enabling secure multi-language script execution and integration with language models like Claude via the Model Context Protocol.5MIT
- AlicenseBqualityAmaintenanceProvides seamless integration with Tailscale's CLI commands and REST API, enabling automated network management and monitoring through a standardized Model Context Protocol interface.18307127MIT
- AlicenseNot gradedqualityDmaintenanceProvides a standardized interface for interacting with Rocketlane's tools and services through the Model Context Protocol, enabling unified API access.1MIT
- AlicenseNot gradedqualityDmaintenanceProvides a standardized interface for interacting with Neon's tools and services through a unified API via the Model Context Protocol.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/privsim/mcp-test-runner'
If you have feedback or need assistance with the MCP directory API, please join our Discord server