プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。レビューとアカウント機能は今後のステップで始まります。
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

MCP Eval Runner

作者:dbsectrainerバージョン 1.0.1i★ –iパソコンで動く
レジストリ名io.github.dbsectrainer/mcp-eval-runner

インストール

概要

作者による説明(英語の原文)

A standardized testing harness for MCP servers and agent workflows

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

  • 接続方法: パソコンで動く
  • トランスポート: stdio
  • カテゴリ: その他
  • 入力が必要なもの:YOUR_API_KEY

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

「秘密」と表示された値は、あなたのアカウントの鍵です。絶対に人に教えたり、チャットに貼り付けたりしないでください。

必要なもの

  • npmNode.jsのインストール(npxコマンドに必要)

どのアプリを使っていますか?

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます

{
  "mcpServers": {
    "eval-runner": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-eval-runner"
      ],
      "env": {
        "YOUR_API_KEY": "your-value"
      }
    }
  }
}

ターミナルでこれを実行します

claude mcp add eval-runner --env YOUR_API_KEY=your-value -- npx -y mcp-eval-runner

動かす前に、空欄の値を入力してください。

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "eval-runner": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-eval-runner"
      ],
      "env": {
        "YOUR_API_KEY": "your-value"
      }
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "eval-runner": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "mcp-eval-runner"
      ],
      "env": {
        "YOUR_API_KEY": "your-value"
      }
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

自分で入力する値

  • YOUR_API_KEY 秘密 必須 env
    Your API key for the service

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント dbsectrainer で確認済みです

  • … 未チェック

    今もメンテナンスされている

    このリポジトリはまだGitHubから読み取っていません

  • … 未チェック

    ライセンスがある

    このリポジトリはまだGitHubから読み取っていません

  • – 対象外

    エンドポイントが応答する

    これはパソコンで動くため、インターネット上のエンドポイントはありません

  • – 対象外

    OAuthでサインイン

    パソコンで動き、代わりにローカルの設定を使います

  • … 未チェック

    ツールの説明に隠れた指示がない

    パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです

その他のほかのサーバーとの比較i

  • このカテゴリのほかの32433件のうち0%よりスターが多い
  • このカテゴリのほかの32433件のうち93%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの32433件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

MCP Eval Runnerは安全ですか?

当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

入力が必要なもの:YOUR_API_KEY

パソコンで動きますか、それともクラウドですか?

あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は–、最新バージョン(1.0.1)がレジストリに届いたのは一昨日です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにNode.jsも必要です。

代わりに使えるものは?

同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Symantec Cloud DLP AIops

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Remote Desktop Commander

作者:desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

クラウドで動く★ 211昨日更新
インストール

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

MCP Eval Runner

npm mcp-eval-runner package

A standardized testing harness for MCP servers and agent workflows. Define test cases as YAML fixtures (steps → expected tool calls → expected outputs), run regression suites directly from your MCP client, and get pass/fail results with diffs — without leaving Claude Code or Cursor.

Tool reference | Configuration | Fixture format | Contributing | Troubleshooting | Design principles

Key features

  • YAML fixtures: Test cases are plain files in version control — diffable, reviewable, and shareable.
  • Two execution modes: Live mode spawns a real MCP server and calls tools via stdio; simulation mode runs assertions against expected_output without a server.
  • Composable assertions: Combine output_contains, output_not_contains, output_equals, output_matches, schema_match, tool_called, and latency_under per step.
  • Step output piping: Reference a previous step's output in downstream inputs via {{steps. .output}}.
  • Regression reports: Compare the current run to any past run and surface what changed.
  • Watch mode: Automatically reruns the affected fixture when files change.
  • CI-ready: Includes a GitHub Action for running evals on every config change.

Requirements

  • Node.js v22.5.0 or newer.
  • npm.

Getting started

Add the following config to your MCP client:

{

"mcpServers": { "eval-runner": { "command": "npx", "args": ["-y", "mcp-eval-runner@latest"] } } }

By default, eval fixtures are loaded from ./evals/ in the current working directory. To use a different path:

{

"mcpServers": { "eval-runner": { "command": "npx", "args": ["-y", "mcp-eval-runner@latest", "--fixtures=~/my-project/evals"] } } }

MCP Client configuration

Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed

Your first prompt

Create a file at evals/smoke.yaml. Use live mode (recommended) by including a server block:

name: smoke

description: "Verify eval runner itself is working" server: command: node args: ["dist/index.js"] steps:

  • id: list_check description: "List available test cases" tool: list_cases input: {} expect: output_contains: "smoke"

Then enter the following in your MCP client:

Run the eval suite.

Your client should return a pass/fail result for the smoke test.

Fixture format

Fixtures are YAML (or JSON) files placed in the fixtures directory. Each file defines one test case.

Top-level fields
FieldRequiredDescription
nameYesUnique name for the test case
descriptionNoHuman-readable description
serverNoServer config — if present, runs in live mode; if absent, runs in simulation mode
stepsYesArray of steps to execute
server block (live mode)
server:

command: node # executable to spawn args: ["dist/index.js"] # arguments env: # optional environment variables MY_VAR: "value"

When server is present the eval runner spawns the server as a child process, connects via MCP stdio transport, and calls each step's tool against the live server.

steps array

Each step has the following fields:

FieldRequiredDescription
idYesUnique identifier within the fixture (used for output piping)
toolYesMCP tool name to call
descriptionNoHuman-readable step description
inputNoKey-value map of arguments passed to the tool (default: {})
expected_outputNoLiteral string used as output in simulation mode
expectNoAssertions evaluated against the step output
Execution modes

Live mode — fixture has a server block:

  • The server is spawned and each step calls the named tool via MCP stdio.
  • Assertions run against the real tool response.
  • Errors from the server cause the step (and by default the case) to fail immediately.

Simulation mode — no server block:

  • No server is started.
  • Each step's output is taken from expected_output (or empty string if absent).
  • Assertions run against that static output.
  • Useful for authoring and CI dry-runs, but output_contains assertions will always fail if expected_output is not set.
Assertion types

All assertions go inside a step's expect block:

expect:

output_contains: "substring" # output includes this text output_not_contains: "error" # output must NOT include this text output_equals: "exact string" # output exactly matches output_matches: "regex pattern" # output matches a regular expression tool_called: "tool_name" # verifies which tool was called latency_under: 500 # latency in ms must be below this threshold schema_match: # output (parsed as JSON) matches JSON Schema type: object required: [id] properties: id: type: number

Multiple assertions in one expect block are all evaluated; the step fails if any assertion fails.

Step output piping

Reference the output of a previous step in a downstream step's input using {{steps. .output}}:

steps:
  • id: search_step tool: search input: query: "mcp eval runner" expected_output: "result: mcp-eval-runner v1.0" expect: output_contains: "mcp-eval-runner"
  • id: summarize_step tool: summarize input: text: "{{steps.search_step.output}}" expected_output: "Summary: mcp-eval-runner v1.0" expect: output_contains: "Summary"

Piping works in both live mode and simulation mode.

Note on create_test_case

Fixtures created with the create_test_case tool do not include a server block. They always run in simulation mode. To use live mode, add a server block manually to the generated YAML file.

Tools

Running
  • run_suite — execute all fixtures in the fixtures directory; returns a pass/fail summary
  • run_case — run a single named fixture by name
  • list_cases — enumerate available fixtures with step counts and descriptions
Authoring
  • create_test_case — create a new YAML fixture file (simulation mode; no server block)
  • scaffold_fixture — generate a boilerplate fixture with placeholder steps and pre-filled assertion comments
Reporting
  • regression_report — compare the current fixture state to the last run; surfaces regressions and fixes
  • compare_results — diff two specific runs by run ID
  • generate_html_report — generate a single-file HTML report for a completed run
Operations
  • evaluate_deployment_gate — CI gate; fails if recent pass rate drops below a configurable threshold
  • discover_fixtures — discover fixture files across one or more directories (respects FIXTURE_LIBRARY_DIRS)

Configuration

--fixtures / --fixtures-dir

Directory to load YAML/JSON eval fixture files from.

Type: string Default: ./evals

--db / --db-path

Path to the SQLite database file used to store run history.

Type: string Default: ~/.mcp/evals.db

--timeout

Maximum time in milliseconds to wait for a single step before marking it as failed.

Type: number Default: 30000

--watch

Watch the fixtures directory and rerun the affected fixture automatically when files change.

Type: boolean Default: false

--format

Output format for eval results.

Type: string Choices: console, json, html Default: console

--concurrency

Number of test cases to run in parallel.

Type: number Default: 1

--http-port

Start an HTTP server on this port instead of stdio transport.

Type: number Default: disabled (uses stdio)

Pass flags via the args property in your JSON config:

{

"mcpServers": { "eval-runner": { "command": "npx", "args": ["-y", "mcp-eval-runner@latest", "--watch", "--timeout=60000"] } } }

Design principles

  • No mocking: Live mode evals run against real servers. Correctness is non-negotiable.
  • Fixtures are text: YAML/JSON in version control; no proprietary formats or databases.
  • Dogfood-first: The eval runner's own smoke fixture tests the eval runner itself.

Verification

Before publishing a new version, verify the server with MCP Inspector to confirm all tools are exposed correctly and the protocol handshake succeeds.

Interactive UI (opens browser):

npm run build && npm run inspect

CLI mode (scripted / CI-friendly):

# List all tools

npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list

List resources and prompts

npx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/list npx @modelcontextprotocol/inspector --cli node dist/index.js --method prompts/list

Call a tool (example — replace with a relevant read-only tool for this plugin)

npx @modelcontextprotocol/inspector --cli node dist/index.js \ --method tools/call --tool-name list_cases

Call a tool with arguments

npx @modelcontextprotocol/inspector --cli node dist/index.js \ --method tools/call --tool-name run_case --tool-arg name=smoke

Run before publishing to catch regressions in tool registration and runtime startup.

Contributing

New assertion types go in src/assertions.ts — implement the Assertion interface and add a test. Integration tests live under tests/ as unit tests and under evals/ as eval fixtures.

npm install && npm test

MCP Registry & Marketplace

This plugin is available on:

Search for mcp-eval-runner.

PopNxに聞く