Mcp Eval Runner

io.github.dbsectrainer由 GitHub 帳號 dbsectrainer 發布v1.0.1更新於 Nov 4, 2026

A standardized testing harness for MCP servers and agent workflows

已驗證STDIO僅桌面開發者工具AI 與機器學習

概覽

AI 產生的概覽

一個本機 MCP 測試工具,讓助理執行以 YAML 定義的評測套件,測試 MCP 伺服器與代理工作流程,並提供通過/失敗結果與差異。

可以做什麼
  • 執行與列出評測案例:跑完整套件或單一具名案例,並列出可用 fixture 及其步驟數。
  • 撰寫 fixture:建立新的 YAML 測試案例,或產生含預留步驟與斷言註解的樣板 fixture。
  • 比較執行結果:與上次執行比對產生回歸報告,或依執行 ID 比對兩次執行,列出回歸、修正與新增案例。
  • 報告與門檻:為已完成的執行產生單一檔案 HTML 報告,並依最低通過率評估 CI 部署門檻。
  • 跨一個或多個目錄探索 fixture,未指定時使用設定的 fixture 目錄。
適用情境
適合維護 MCP 伺服器或代理工作流程、希望擁有可納入版本控制且可重複執行的測試,並直接在 Claude Code、Cursor 等用戶端中執行的人。也適合在通過率下降時阻擋部署的 CI 流程。
執行需求
透過 npx 以 stdio 本機程序執行,需要 Node.js v22.5.0 或更新版本以及 npm。fixture 預設位於 ./evals,執行歷史存放在本機 SQLite 檔案。選用參數可設定 fixture 目錄、逾時、監看模式、輸出格式、並行數與 HTTP 連接埠。
安裝前請注意
即時模式會把 fixture 的 server 區塊指定的伺服器當成子程序啟動並呼叫其工具,因此 fixture 可執行任意指令並觸發真實的工具操作,包括寫入。fixture 的 server 區塊也可攜帶環境變數,其中可能包含密鑰。清單宣告了一個名為 YOUR_API_KEY 的必填密鑰,但 README 未說明其用途。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Mcp Eval Runner,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

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.<step_id>.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:

json
{  "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:

json
{  "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:

yaml
name: smokedescription: "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)

yaml
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:

yaml
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.<step_id>.output}}:

yaml
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:

json
{  "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):

bash
npm run build && npm run inspect

CLI mode (scripted / CI-friendly):

bash
# List all toolsnpx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
# List resources and promptsnpx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/listnpx @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 argumentsnpx @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.

bash
npm install && npm test

MCP Registry & Marketplace

This plugin is available on:

Search for mcp-eval-runner.

來源:README.md,提交 bb72647

工具

10

run_suite

Execute all fixtures in the fixtures directory. Returns a pass/fail summary. Execution modes: Live mode: fixture has a 'server' block with command/args — spawns the server and calls tools via real MCP stdio transport. Simulation mode: no server block — assertions run against expected_output fields. Assertion types supported in fixture expect blocks: output_contains: "substring" output_not_contains: "substring" output_equals: "exact text" output_matches: "regex" tool_called: "tool_name" latency_under: 500 schema_match: { type: "object", required: ["result"], properties: { result: { type: "string" } } } Step output piping: use {{steps.<step_id>.output}} in input values to reference the output of a previous step.

無需輸入參數。

run_case

Run a single named test case from the fixtures directory. Assertion types supported in fixture expect blocks: output_contains: "substring" output_equals: "exact text" tool_called: "tool_name" latency_under: 500 schema_match: { type: "object", required: ["id"], properties: { id: { type: "number" } } }

輸入參數name必填

list_cases

Enumerate all available fixtures with their step counts and assertion types.

無需輸入參數。

create_test_case

Create a new YAML fixture file in the fixtures directory. Supported assertion types in each step's expect block: output_contains: "substring" — checks output includes this text output_equals: "exact" — checks exact output match tool_called: "tool_name" — verifies which tool was called latency_under: 500 — asserts response time under N ms schema_match: { type: 'object', ... } — validates output JSON against schema

輸入參數name必填steps必填description

regression_report

Compare current state to the last run and return what changed (regressions, fixes, new cases).

無需輸入參數。

compare_results

Diff two named run results by run ID. Shows regressions, fixes, new and removed cases.

輸入參數run_id_a必填run_id_b必填

generate_html_report

Generate a full single-file HTML report for a completed run. The report includes: suite summary (pass/fail counts, duration), per-case drill-down with per-assertion pass/fail details, and color-coded status (green=pass, red=fail, yellow=error). Use run_suite or run_case first, then pass the returned run_id here.

輸入參數run_id必填

scaffold_fixture

Generate a boilerplate YAML fixture file in the fixtures directory. Each tool name provided becomes a documented step with placeholder input parameters and all supported assertion types pre-filled as comments. Example: scaffold_fixture({ name: 'search_test', tool_names: ['search', 'summarize'] }) Supported assertion types (pre-filled as TODOs in the generated file): output_contains, output_equals, tool_called, latency_under, schema_match

輸入參數name必填tool_names必填

evaluate_deployment_gate

CI gate — evaluate whether recent eval runs meet a minimum pass rate threshold. Fails (passed: false) if the pass rate of recent runs drops below min_pass_rate. Use this in CI pipelines to block deployments on regressions.

輸入參數lookback_runsmin_pass_rate必填workflow_name

discover_fixtures

Discover fixture files across one or more directories. Returns a list of fixtures with their names, paths, and step counts. If no dirs are provided, uses the configured fixtures directory and FIXTURE_LIBRARY_DIRS env var (colon-separated list of paths).

輸入參數dirs

版本歷史

2
  1. v1.0.1最新Nov 4, 2026
  2. v1.0.0Sep 16, 2026

評分

已滿足適用檢查項的 90%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分
  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具必需15 分
  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分