Skip to main content
Glama

テストランナーMCP

複数のテストフレームワークからのテスト結果を実行および解析するためのモデルコンテキストプロトコル(MCP)サーバー。このサーバーは、テストの実行と出力の処理のための統一されたインターフェースを提供し、以下をサポートします。

  • Bats(Bash自動テストシステム)

  • Pytest (Python テストフレームワーク)

  • フラッターテスト

  • Jest (JavaScript テストフレームワーク)

  • Goテスト

  • 錆試験(貨物試験)

  • 汎用(任意のコマンド実行用)

インストール

npm install test-runner-mcp

Related MCP server: Tailscale MCP Server

前提条件

それぞれのテスト タイプに対して、次のテスト フレームワークをインストールする必要があります。

使用法

構成

テストランナーを MCP 設定に追加します (例: claude_desktop_config.jsonまたは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"
      }
    }
  }
}

注: Flutter テストの場合は、次のものを必ず置き換えてください。

  • /opt/homebrew/Caskroom/flutter/3.27.2/flutterを実際の Flutter インストールパスに置き換えます。

  • /Users/username/.pub-cache実際のpubキャッシュパスに置き換えます

  • PATHを更新してシステムの実際のパスを追加します

これらの値は、次のコマンドを実行することで見つけることができます。

# Get Flutter root
flutter --version

# Get pub cache path
echo $PUB_CACHE   # or default to $HOME/.pub-cache

# Get Flutter binary path
which flutter

テストの実行

次のパラメータを指定してrun_testsツールを使用します。

{
  "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"
}

各フレームワークの例:

// 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
  }
}

セキュリティ機能

テスト ランナーには、特にgenericフレームワークに対して潜在的に有害なコマンドの実行を防ぐためのセキュリティ機能が組み込まれています。

  1. コマンド検証

    • デフォルトでsudoとsuをブロックします

    • rm -rf /のような危険なコマンドを防止します

    • 安全な場所以外でのファイルシステムの書き込み操作をブロックします

  2. 環境変数のサニタイズ

    • 潜在的に危険な環境変数を除外します

    • 重要なシステム変数の上書きを防止

    • 安全なパス処理を保証する

  3. 設定可能なセキュリティ

    • 必要に応じて、 securityOptionsでセキュリティ制限をオーバーライドします。

    • セキュリティ機能のきめ細かな制御

    • 標準テスト使用時のデフォルトの安全設定

設定できるセキュリティ オプション:

{
  "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テストのサポート

テスト ランナーには、Flutter テストの強化されたサポートが含まれています。

  1. 環境設定

    • Flutter環境の自動構成

    • PATHとPUB_CACHEの設定

    • Flutterのインストール検証

  2. エラー処理

    • スタックトレースの収集

    • アサーションエラー処理

    • 例外キャプチャ

    • テスト失敗検出

  3. 出力処理

    • 完全なテスト出力キャプチャ

    • スタックトレースの保存

    • 詳細なエラー報告

    • 生の出力の保存

Rustテストのサポート

テスト ランナーは、Rust のcargo testに特化したサポートを提供します。

  1. 環境設定

    • より適切なエラーメッセージを表示するために、RUST_BACKTRACE=1 を自動的に設定します。

  2. 出力解析

    • 個々のテスト結果を解析する

    • 失敗したテストの詳細なエラーメッセージをキャプチャします

    • 無視されたテストを特定する

    • 概要情報を抽出します

汎用テストサポート

CI/CD パイプライン、 act経由の GitHub Actions、またはその他のコマンド実行の場合、汎用フレームワークは以下を提供します。

  1. 自動出力分析

    • 出力を論理ブロックに分割する試み

    • セクションヘッダーを識別します

    • 合格/不合格の指標を検出

    • 未知のフォーマットでも適切な出力構造を提供します

  2. 柔軟な統合

    • 任意のシェルコマンドで動作します

    • 特定のフォーマット要件はありません

    • act 、Docker、カスタムスクリプトなどのツールとの統合に最適

  3. セキュリティ機能

    • 有害な操作を防ぐためのコマンド検証

    • 必要に応じて特定の権限を許可するように設定できます

出力形式

テスト ランナーは、完全なテスト出力を保持しながら構造化された出力を生成します。

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
}

結果は指定された出力ディレクトリに保存されます。

  • test_output.log : 生のテスト出力

  • test_errors.log : エラーメッセージ(ある場合)

  • test_results.json : 構造化されたテスト結果

  • summary.txt : 人間が読める要約

発達

設定

  1. リポジトリをクローンする

  2. 依存関係をインストールします:

    npm install
  3. プロジェクトをビルドします。

    npm run build

テストの実行

npm test

テスト スイートには、サポートされているすべてのフレームワークのテストが含まれており、成功したテスト シナリオと失敗したテスト シナリオの両方が検証されます。

CI/CD

このプロジェクトでは、継続的インテグレーションのために GitHub Actions を使用しています。

  • Node.js 18.x および 20.x での自動テスト

  • テスト結果をアーティファクトとしてアップロード

  • 依存関係の自動更新用に設定されたDependabot

貢献

  1. リポジトリをフォークする

  2. 機能ブランチを作成する

  3. 変更をコミットする

  4. ブランチにプッシュする

  5. プルリクエストを作成する

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

Available Tools

1 tool
run_testsC

Run tests and capture output

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesTest command to execute (e.g., "bats tests/*.bats")
envNoEnvironment variables for test execution
frameworkYesTesting framework being used
outputDirNoDirectory to store test results
securityOptionsNoSecurity options for command execution
timeoutNoTest execution timeout in milliseconds (default: 300000)
workingDirYesWorking directory for test execution

TDQS

C2.7/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

  1. 1 tool updatev1.0.0
    • First observedrun_tests

TDQS

C2.9/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

  • Direct access to Cypress tests results and accessibility reports in your AI workflow.

  • Approved test intent, reviewed Playwright automation and run evidence, inside your editor.

  • Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.

  • Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Facilitates isolated code execution within Docker containers, enabling secure multi-language script execution and integration with language models like Claude via the Model Context Protocol.
    5
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a standardized interface for interacting with Rocketlane's tools and services through the Model Context Protocol, enabling unified API access.
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a standardized interface for interacting with Neon's tools and services through a unified API via the Model Context Protocol.
    MIT