Mcp Eval Runner

io.github.dbsectrainerPublished by GitHub account dbsectrainerv1.0.1Updated Nov 4, 2026

A standardized testing harness for MCP servers and agent workflows

VerifiedSTDIODesktop onlyDeveloper ToolsAI & ML

Overview

AI-generated overview

A local MCP testing harness that lets an assistant run YAML-defined eval suites against MCP servers and agent workflows, with pass/fail results and diffs.

What you can do
  • Run and list eval fixtures: execute a whole suite or a single named case, and enumerate available fixtures with step counts.
  • Author fixtures: create new YAML test cases or scaffold boilerplate fixtures with placeholder steps and assertion comments.
  • Compare runs: produce regression reports against the last run or diff two runs by ID, showing regressions, fixes and new cases.
  • Report and gate: generate a single-file HTML report for a completed run and evaluate a CI deployment gate against a minimum pass rate.
  • Discover fixtures across one or more directories, falling back to the configured fixtures directory.
When to use it
Useful when you maintain MCP servers or agent workflows and want repeatable, version-controlled tests you can run from inside Claude Code, Cursor or a similar client. Also fits CI pipelines that should block deployments when pass rates drop.
Requirements
Runs locally via npx as a stdio process; needs Node.js v22.5.0 or newer and npm. Fixtures default to ./evals and run history is stored in a local SQLite file. Optional flags set the fixtures directory, timeout, watch mode, output format, concurrency and an HTTP port.
Before you install
Live mode spawns the server named in a fixture's server block as a child process and calls its tools, so fixtures can execute arbitrary commands and trigger real tool actions, including writes. Fixture server blocks can also carry environment variables, which may include secrets. The manifest declares a required secret named YOUR_API_KEY, though the README does not explain what it is used for.

Installation

In SourceWeft

  1. Open Mcp Eval Runner in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

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.

Source: README.md at commit bb72647

Tools

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.

Takes no parameters.

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

Parametersnamerequired

list_cases

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

Takes no parameters.

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

Parametersnamerequiredstepsrequireddescription

regression_report

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

Takes no parameters.

compare_results

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

Parametersrun_id_arequiredrun_id_brequired

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.

Parametersrun_idrequired

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

Parametersnamerequiredtool_namesrequired

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.

Parameterslookback_runsmin_pass_raterequiredworkflow_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).

Parametersdirs

Version history

2
  1. v1.0.1LatestNov 4, 2026
  2. v1.0.0Sep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts