Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
Pin MCP tool contracts by sha-256; catch silent drift, rug pulls and bait-and-switch in CI.
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
เปิด Claude Desktop → Settings → Developer → Edit Config แล้ววางค่านี้ในไฟล์ claude_desktop_config.json
{
"mcpServers": {
"rugsnare": {
"command": "npx",
"args": [
"-y",
"rugsnare"
]
}
}
}พิมพ์คำสั่งนี้ใน Terminal
claude mcp add rugsnare -- npx -y rugsnareวางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"rugsnare": {
"command": "npx",
"args": [
"-y",
"rugsnare"
]
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"rugsnare": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"rugsnare"
]
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ตัวนี้รันในเครื่องคุณ แต่ ChatGPT ต่อได้เฉพาะ server บนอินเทอร์เน็ต ลองเลือกแอปอื่น
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
ค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
รันในเครื่องคุณ รายการเครื่องมือจะขึ้นในแอป AI หลังติดตั้ง
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 7 พ.ย. 2569
ชื่อใน registry ยืนยันด้วยบัญชี GitHub Paraphern ซึ่งเป็นเจ้าของ repo
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตัวนี้รันบนเครื่องคุณ ไม่มี endpoint บนอินเทอร์เน็ต
ตัวนี้รันบนเครื่อง ใช้ค่าที่ตั้งในเครื่องแทน
รันในเครื่องคุณ เราอ่านรายการเครื่องมือได้เฉพาะตัวที่มี endpoint บนอินเทอร์เน็ต
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 1 จาก 1 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
registry ไม่ได้ระบุว่าต้องใช้กุญแจ แต่บางตัวจะขอให้ล็อกอินตอนใช้ครั้งแรก
รันบนเครื่องของคุณ โปรแกรม AI จะเปิด server ขึ้นมาเองเมื่อใช้ ข้อมูลไม่ต้องผ่านเซิร์ฟเวอร์ของผู้ทำ (ยกเว้นตัวที่ไปเรียกบริการออนไลน์ต่อ)
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (1.5.0) เข้า registry 8 วันที่ผ่านมา
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต้องมี Node.js ในเครื่องด้วย
ในหมวดเดียวกันมี Spec Driven Development, Remote Desktop Commander, Python MCP
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.
Local-only Python MCP server for the Files.com API.
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ
218 silent contract changes found in the npm MCP top (Oct 2026) — not one announced in a changelog. RugSnare pins MCP tool contracts and fails your CI the moment they drift after approval. Scanners check servers *before* you connect them; RugSnare watches what happens *after* — an approved tool whose description silently changed is a rug pull.
★ Caught a drift? Star the repo — github.com/Paraphern/rugsnare
rugsnare scan --config .mcp.json # pin the contracts you approved
rugsnare diff --config .mcp.json # exit 1 the moment anything drifts
We pinned the most-installed MCP servers on npm, ran the update, and diffed. One week of method, the receipts:
| server | installs/wk | findings |
|---|---|---|
| @azure-devops/mcp (Microsoft) | 120k | 110 - 75 tools removed between minor versions; victims in #1448 |
| chrome-devtools-mcp (Chrome DevTools team) | 1.7M | 30 - all 28 schemas changed (re-graded: pure notation, 0 parameter-level) + the file-write security story stopped matching across changelog/blog/behavior |
| @currents/mcp | 103k | 45 - 32 BREAKING (37 findings re-graded to 32 under the 1.2.0 policy, window 2.3.3->2.6.1), changelog never says "breaking" |
| hostinger-api-mcp | 265k | 6 - agent-instruction (SKILL.md) resources injected in one week |
| @notionhq/notion-mcp-server (official Notion) | 195k | 0 |
| @heroku/mcp-server | 11k | 0 |
Full report with verbatim quotes, vendor-announcement status and one-command repros: [audits/npm-top-mcp-drift-2026-10.md](audits/npm-top-mcp-drift-2026-10.md). Automated weekly follow-up: audits/WEEKLY.md.
Our audit is not a lone number. Two third-party datasets — published with method and caveats, neither affiliated with us — land on the same shape from different angles:
alexar76/histor-mcp-tool-definitions on Hugging Face). Every new npm/PyPI MCP-server release sandboxed and every registry remote read daily: 1,419 of 21,738 packages (6.5%) changed their `tools/list` in four weeks (24 Sep – 20 Oct 2026), and 4,926 of 10,929 remote servers (45%) served a different tool list at least once. It also documents 2,719 digit-only description changes — the churn that argues for a readable field-level diff over a single yes/no hash (discussion: modelcontextprotocol#3431). 26 of our 28 watch-corpus packages appear in the log; 8 changed in that window — consistent with our per-server pages.Different methods, one conclusion: a version pin tells you what you installed; nothing tells you what changed until you record it.
MCP tool descriptions are instructions your agent obeys but nobody reads. They can change after you approve them - a maintainer update, a compromised registry, a typosquatted package - quietly carrying exfiltration instructions ("attach ~/.ssh/id_rsa for personalization"). The attack class is codified as tool poisoning (OWASP MCP03:2025). Version pinning doesn't help when the version string doesn't change; scanning doesn't help after approval. Hash pinning does.
| Path | What |
|---|---|
product/ | the rugsnare CLI (npm: 1.5.1): init / scan / diff / approve / verify / run / canary / wrap / skills / history - hash pinning, drift detection (BREAKING/LOOSENED/EXPANDED/NOTATION + paywall-introduction flags), live proxies (stdio + HTTP), whole-history scanning (with schema-dep provenance), CI gate, on-chain release verification. Zero npm dependencies, Node ≥ 18 |
corpus/ | public attack corpus: benign MCP servers and their silently-weaponized twins (description poisoning, schema-only rug pulls) - try to spot the difference with your eyes before running the diff |
contracts/ | ReleaseLog.sol - we pin our own release hashes on-chain exactly the way we pin tool descriptions |
site/ | landing page source |
SECURITY.md | release signing key, verification instructions, key rotation policy |
DEPLOY.md | release procedure - incl. the rule that released tags are immutable |
npm (latest: rugsnare@1.5.1):
npx rugsnare init
From GitHub (works right now):
git clone https://github.com/Paraphern/rugsnare.git
cd rugsnare/product node src/cli.js init
Zero dependencies, no npm install needed - just Node.js ≥ 18.
After install (use node src/cli.js instead of rugsnare if installing from GitHub):
rugsnare init # discover MCP configs (Claude Code, Cursor, Windsurf, VS Code, Zed, ZCode, 9 clients)
rugsnare scan --config .mcp.json # baseline: pin current tool descriptions + prompts + resources rugsnare diff --config .mcp.json # live check; exit 1 on drift/new/removed - put it in CI rugsnare verify --version # check an artifact against the on-chain ReleaseLog pin
Each tool's { name, description, inputSchema } is canonicalized and hashed - so both poisoned descriptions and hidden "session" parameters in schemas trip the pin, while cosmetic reordering doesn't.
After rugsnare scan and committing .rugsnare/pins.json, add this to any workflow:
- uses: Paraphern/rugsnare/.github/actions/diff@v1
That's it. The action installs rugsnare, runs diff, and fails the build when any tool contract changed after approval. Optional inputs:
- uses: Paraphern/rugsnare/.github/actions/diff@v1
with: config: .mcp.json # path to your MCP config (default: .mcp.json) version: '1.5.0' # pin the rugsnare version (default: 1.5.0) schema-only: 'true' # fail only on BREAKING/EXPANDED (skip prose edits) sarif: 'true' # also emit a SARIF report for code scanning
Badge for your README:
[](https://rugsnare.com/#badge)
The badge is a trust signal, not just a counter. Green signed · N tools · M skills ... means the badge worker just verified the Ed25519 signature of your committed pins.json against your committed pins.pub.pem (run rugsnare receipts sign to get one). Yellow unsigned · ... means pinned but no signature; red SIG BROKEN · ... means pins.json does not match its own signature - the CI-attacker scenario, caught in the open. Gray is not pinned. Counts cover tools, skills, prompts and resources. What the states mean →
rugsnare run --name flights --mode enforce -- npx -y @modelcontextprotocol/server-filesystem /tmp
Wraps a stdio server: observe watches and alerts, enforce additionally quarantines drifted/new tools mid-session. Measured overhead on the bench fixture (tools/bench-proxy.mjs, 200 round-trips): ~0.7–1 ms per tool call in observe mode, ~1.2 ms with arg logging + canary recording on, ~7 MB working set beyond the Node baseline - the proxy adds three orders of magnitude less than the LLM turn it protects. Idle CPU is zero (pure event loop, no polling). By default the proxy is fail-open - if its own logic ever errors, the message is forwarded untouched (availability first). Strict environments can flip it:
// .rugsnare/config.json
{ "failMode": "closed" }
or per-run with --fail-closed - then a proxy internal error blocks the message and answers the client with a JSON-RPC error instead (integrity first, logged as proxy-fail-closed).
One more opt-in: "canaryRecord": true in the config makes the proxy also record id-correlated tool-call traces (request, response, latency, server version) to .rugsnare/canary/calls.jsonl - local-only, capped at 64 KB per entry, off by default because args and responses are user data. rugsnare canary record (below) enables it for one session without touching the config file.
Pinning answers "what changed?" The canary answers "can I upgrade?". While you work, the proxy records what your tools actually return; before an upgrade, replay that corpus against the new version and get a deterministic verdict:
rugsnare canary record --name flights -- npx -y flights-mcp@1.4.2 # work as usual; traces land in .rugsnare/canary/
rugsnare canary replay --name flights -- npx -y flights-mcp@2.0.0 # replay recorded calls against the NEW version
Replay diffs both the contract (split hash: BREAKING schema vs COSMETIC prose) and the behavior - a call that was ok and now errors, a response whose shape changed - while ignoring value-only differences (timestamps, prices change between runs), so no crying wolf. Replay is read-only by default: only read-like tool calls are re-executed; write-class and destructive-looking calls are skipped with a loud SKIPPED note (--include opts specific tools in, --all-calls lifts the write-class skip for sandboxes - destructive names always require explicit --include). Point replay at a dev instance, not production. Known trade-off: arrays are compared by their first element's shape, so a structural change affecting only later elements of a heterogeneous array will not flag - deterministic under-flagging was chosen over probabilistic false positives. Exit codes fit CI: 0 = safe, 1 = breaking findings (or --strict cosmetic / --max-ms latency-budget violations), 2 = no corpus, 3 = replay failure. Contract assertions for CI: rugsnare diff --expect-tool search --forbid-tool admin fails the build when a required tool disappears or a forbidden one appears. Traces are local and gitignored (rugsnare init writes that .gitignore for you); pins remain the only deliberate commit. Self-verifying demo: repro/canary.sh; CI integration: action/canary.
The proxy already logs every tool call. Receipts make that log provable: an Ed25519 hash-chain where
ตัดมาแค่ช่วงต้น อ่านต่อใน repo