Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
A standardized testing harness for MCP servers and agent workflows
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
YOUR_API_KEYValues marked secret are keys to your account. Never share them or paste them into a chat.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"eval-runner": {
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "your-value"
}
}
}
}Run this in your terminal
claude mcp add eval-runner --env YOUR_API_KEY=your-value -- npx -y mcp-eval-runnerFill in the empty values before running it.
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"eval-runner": {
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"eval-runner": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account dbsectrainer, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
You need to fill in: YOUR_API_KEY
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (1.0.1) reached the registry 3 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, topo^alpin
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Avalanche bulletins and mountain weather forecasts for any place in the Alps.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
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
expected_output without a server.output_contains, output_not_contains, output_equals, output_matches, schema_match, tool_called, and latency_under per step.{{steps. .output}}.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"] } } }
Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed
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:
Then enter the following in your MCP client:
Run the eval suite.
Your client should return a pass/fail result for the smoke test.
Fixtures are YAML (or JSON) files placed in the fixtures directory. Each file defines one test case.
| Field | Required | Description |
|---|---|---|
name | Yes | Unique name for the test case |
description | No | Human-readable description |
server | No | Server config — if present, runs in live mode; if absent, runs in simulation mode |
steps | Yes | Array 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 arrayEach step has the following fields:
| Field | Required | Description |
|---|---|---|
id | Yes | Unique identifier within the fixture (used for output piping) |
tool | Yes | MCP tool name to call |
description | No | Human-readable step description |
input | No | Key-value map of arguments passed to the tool (default: {}) |
expected_output | No | Literal string used as output in simulation mode |
expect | No | Assertions evaluated against the step output |
Live mode — fixture has a server block:
Simulation mode — no server block:
expected_output (or empty string if absent).output_contains assertions will always fail if expected_output is not set.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.
Reference the output of a previous step in a downstream step's input using {{steps. .output}}:
steps:
Piping works in both live mode and simulation mode.
create_test_caseFixtures 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.
run_suite — execute all fixtures in the fixtures directory; returns a pass/fail summaryrun_case — run a single named fixture by namelist_cases — enumerate available fixtures with step counts and descriptionscreate_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 commentsregression_report — compare the current fixture state to the last run; surfaces regressions and fixescompare_results — diff two specific runs by run IDgenerate_html_report — generate a single-file HTML report for a completed runevaluate_deployment_gate — CI gate; fails if recent pass rate drops below a configurable thresholddiscover_fixtures — discover fixture files across one or more directories (respects FIXTURE_LIBRARY_DIRS)--fixtures / --fixtures-dirDirectory to load YAML/JSON eval fixture files from.
Type: string Default: ./evals
--db / --db-pathPath to the SQLite database file used to store run history.
Type: string Default: ~/.mcp/evals.db
--timeoutMaximum time in milliseconds to wait for a single step before marking it as failed.
Type: number Default: 30000
--watchWatch the fixtures directory and rerun the affected fixture automatically when files change.
Type: boolean Default: false
--formatOutput format for eval results.
Type: string Choices: console, json, html Default: console
--concurrencyNumber of test cases to run in parallel.
Type: number Default: 1
--http-portStart 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"] } } }
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
npx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/list npx @modelcontextprotocol/inspector --cli node dist/index.js --method prompts/list
npx @modelcontextprotocol/inspector --cli node dist/index.js \ --method tools/call --tool-name list_cases
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.
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
This plugin is available on:
Search for mcp-eval-runner.