Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
A standardized testing harness for MCP servers and agent workflows
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
YOUR_API_KEYค่าที่ติดป้ายความลับคือกุญแจของบัญชีคุณ อย่าส่งให้ใคร และอย่าวางในแชต
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
เปิด Claude Desktop → Settings → Developer → Edit Config แล้ววางค่านี้ในไฟล์ claude_desktop_config.json
{
"mcpServers": {
"eval-runner": {
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "ใส่ค่าของคุณ"
}
}
}
}พิมพ์คำสั่งนี้ใน Terminal
claude mcp add eval-runner --env YOUR_API_KEY='ใส่ค่าของคุณ' -- npx -y mcp-eval-runnerเติมค่าที่เว้นว่างไว้ก่อนรัน
วางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"eval-runner": {
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "ใส่ค่าของคุณ"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"eval-runner": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"mcp-eval-runner"
],
"env": {
"YOUR_API_KEY": "ใส่ค่าของคุณ"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ตัวนี้รันในเครื่องคุณ แต่ ChatGPT ต่อได้เฉพาะ server บนอินเทอร์เน็ต ลองเลือกแอปอื่น
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
ค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
รันในเครื่องคุณ รายการเครื่องมือจะขึ้นในแอป AI หลังติดตั้ง
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 6 พ.ย. 2569
ชื่อใน registry ยืนยันด้วยบัญชี GitHub dbsectrainer ซึ่งเป็นเจ้าของ repo
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตัวนี้รันบนเครื่องคุณ ไม่มี endpoint บนอินเทอร์เน็ต
ตัวนี้รันบนเครื่อง ใช้ค่าที่ตั้งในเครื่องแทน
รันในเครื่องคุณ เราอ่านรายการเครื่องมือได้เฉพาะตัวที่มี endpoint บนอินเทอร์เน็ต
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 1 จาก 1 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
ต้องใส่ค่าเหล่านี้: YOUR_API_KEY
รันบนเครื่องของคุณ โปรแกรม AI จะเปิด server ขึ้นมาเองเมื่อใช้ ข้อมูลไม่ต้องผ่านเซิร์ฟเวอร์ของผู้ทำ (ยกเว้นตัวที่ไปเรียกบริการออนไลน์ต่อ)
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (1.0.1) เข้า registry เมื่อวานซืน
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต้องมี Node.js ในเครื่องด้วย
ในหมวดเดียวกันมี Spec Driven Development, Remote Desktop Commander, Apify MCP Server
server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว
อ่านการ์ด:★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า 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.
Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ
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.