Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
Read-only NATS and JetStream observability: trace a request across streams, rank what is broken.
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
NATS_TRAIL_API, NATS_TRAIL_TOKENค่าที่ติดป้ายความลับคือกุญแจของบัญชีคุณ อย่าส่งให้ใคร และอย่าวางในแชต
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
เปิด Claude Desktop → Settings → Developer → Edit Config แล้ววางค่านี้ในไฟล์ claude_desktop_config.json
{
"mcpServers": {
"nats-trail": {
"command": "npx",
"args": [
"-y",
"@nats-trail/mcp"
],
"env": {
"NATS_TRAIL_API": "ใส่ค่าของคุณ",
"NATS_TRAIL_TOKEN": "ใส่ค่าของคุณ"
}
}
}
}พิมพ์คำสั่งนี้ใน Terminal
claude mcp add nats-trail --env NATS_TRAIL_API='ใส่ค่าของคุณ' --env NATS_TRAIL_TOKEN='ใส่ค่าของคุณ' -- npx -y @nats-trail/mcpเติมค่าที่เว้นว่างไว้ก่อนรัน
วางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"nats-trail": {
"command": "npx",
"args": [
"-y",
"@nats-trail/mcp"
],
"env": {
"NATS_TRAIL_API": "ใส่ค่าของคุณ",
"NATS_TRAIL_TOKEN": "ใส่ค่าของคุณ"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"nats-trail": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@nats-trail/mcp"
],
"env": {
"NATS_TRAIL_API": "ใส่ค่าของคุณ",
"NATS_TRAIL_TOKEN": "ใส่ค่าของคุณ"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ตัวนี้รันในเครื่องคุณ แต่ ChatGPT ต่อได้เฉพาะ server บนอินเทอร์เน็ต ลองเลือกแอปอื่น
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
NATS_TRAIL_API envค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
รันในเครื่องคุณ รายการเครื่องมือจะขึ้นในแอป AI หลังติดตั้ง
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 7 พ.ย. 2569
ชื่อใน registry ยืนยันด้วยบัญชี GitHub solsolettidev ซึ่งเป็นเจ้าของ repo
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตัวนี้รันบนเครื่องคุณ ไม่มี endpoint บนอินเทอร์เน็ต
ตัวนี้รันบนเครื่อง ใช้ค่าที่ตั้งในเครื่องแทน
รันในเครื่องคุณ เราอ่านรายการเครื่องมือได้เฉพาะตัวที่มี endpoint บนอินเทอร์เน็ต
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 1 จาก 1 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
ต้องใส่ค่าเหล่านี้: NATS_TRAIL_TOKEN
รันบนเครื่องของคุณ โปรแกรม AI จะเปิด server ขึ้นมาเองเมื่อใช้ ข้อมูลไม่ต้องผ่านเซิร์ฟเวอร์ของผู้ทำ (ยกเว้นตัวที่ไปเรียกบริการออนไลน์ต่อ)
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (0.6.1) เข้า registry 35 วันที่ผ่านมา
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต้องมี Node.js ในเครื่องด้วย
ในหมวดเดียวกันมี Spec Driven Development, Remote Desktop Commander, Zendesk
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.
Zendesk MCP Pack — tickets, users, organizations via OAuth.
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ
Give an AI agent safe access to your production event bus.
A web UI, a CLI and an MCP server over one bounded query engine — so humans and agents debug NATS from the same source of truth.
Every NATS GUI answers *"what is in this stream?"*. That is the easy question.
The hard question in an event-driven system is "why did this one flow fail?" — and answering it means following a single request_id across four streams, three services and a dead-letter subject. Today you do that by hand, with a terminal per stream.
NATS Trail answers that question directly, and exposes the answer to agents as a typed, bounded, read-only tool contract — so you can point Claude at production and ask.
nats-trail trace --request-id req-0001d --limit 20
Or, from an agent: *"Why did the refresh for s3-events fail?"* — and it lands on the message that actually broke, with the retry state and the correlation ids already extracted:
There are several NATS MCP servers. They shell out to the nats CLI, return raw dumps, and expose publish and delete while describing themselves as read-only.
NATS Trail treats the agent surface as a contract, not a wrapper:
| NATS Trail | Typical NATS MCP server | |
|---|---|---|
| Tool schemas | Explicit JSON input and output schemas per tool | None, or input only |
| Result size | limit is required, capped at 200, with cursors | Unbounded |
| Long scans | maxScan budget with explicit truncation warnings | Scans until it dies |
| Message shape | subject, timestamp, stream/seq, truncation flag, extracted request_id / correlation_id | Raw payload dump |
| Errors | Structured envelope with code and retriable | Stack traces or plain strings |
| Writes | Unreachable from the agent runtime | publish, KV and object writes exposed |
| Audit | Every call logged with origin and token identity; mutations with their arguments | None |
NATS Trail *can* write: publish, purge, delete messages, consumers and streams. Those live behind /api/mutate, reachable from the UI and the CLI.
executeMcpTool() receives an McpRuntimeData interface that exposes only read functions. There is no disabled publish behind a feature flag — there is no `publish` to call. A misconfigured environment variable cannot purge your production stream, because the code path does not exist. CLI write commands additionally refuse to run under --agent, and the test suite reads the source to assert none of this has been quietly undone.
This is the only reason it is reasonable to hand an agent a prod context.
npx nats-trail serve
Open http://127.0.0.1:4000 — one process serves the UI and the API.
Prefer containers? The compose file brings up NATS Trail next to a JetStream-enabled server:
docker compose up
On Kubernetes, the Helm chart declares contexts and correlation keys in values.yaml and keeps credentials in a Secret:
helm install nats-trail ./charts/nats-trail -f my-values.yaml
See charts/nats-trail/README.md for declarative config, why it is a single-replica StatefulSet, and how authentication is delegated to whatever fronts the service.
From source
git clone https://github.com/solsolettidev/nats-trail
cd nats-trail npm install npm start
Development with hot reload
npm run dev
/api and /ws to the bridge)npm run dev runs the TypeScript watcher, the API bridge and the UI together.
Requirements: Node.js >= 22 (for the built-in SQLite used by the correlation index) and a reachable NATS server (nats-server -js is fine).
Point any MCP client at the stdio server. For Claude Code:
claude mcp add nats-trail -- npx -y @nats-trail/mcp
Or wire it manually:
{
"mcpServers": { "nats-trail": { "command": "natstrail-mcp", "env": { "NATS_TRAIL_API": "http://127.0.0.1:4000", "NATS_TRAIL_TOKEN": " " } } } }
Twenty-five read-only tools, all returning the same envelope:
# start here when the topology is unknown
natstrail.discover_subjects subjects that carry traffic + inferred payload shapes natstrail.get_health_summary what is broken right now, ranked natstrail.reconstruct_flow the causal chain for one request_id natstrail.enrich_incident flat context for an incident: flow + dead letters + health
natstrail.search_messages natstrail.get_message_detail natstrail.trace_by_request_id natstrail.trace_by_correlation_id natstrail.search_dlq natstrail.run_filter
natstrail.list_streams natstrail.get_stream_info natstrail.list_consumers natstrail.list_kv_buckets natstrail.list_kv_keys natstrail.get_kv_history natstrail.list_object_buckets natstrail.list_objects
natstrail.get_server_health natstrail.list_server_connections natstrail.list_contexts natstrail.get_connection_status natstrail.list_filters natstrail.list_audit natstrail.enrich_sentry
See docs/mcp-agent.md.
┌── Web UI explore visually, save filters
Query Engine ───┼── CLI scripts, pipelines, humans in a terminal (core) └── MCP + HTTP API agents, Sentry, dashboards
A filter you save in the UI is the same filter nats-trail filter run executes, and the same one natstrail.run_filter hands an agent. Configure a context once; use it everywhere.
nats-trail binary: query commands, serve, and an interactive shell.See docs/architecture.md.
Inspect — context selector (local / dev / staging / prod) with a prod confirmation gate, live subject subscription, JSON pretty print with tree view and in-payload search, stream and consumer browsing, auto-detected DLQ panel.
JetStream — streams, subjects, counts and consumer health. and a selected message rendered as a JSON tree"> NATS Core — live subject subscription with filters.
DLQ — auto-detected dead letters with reason and origin.
Viewer — tree, raw, search, fullscreen, copy-path.
Understand — subject discovery infers payload shapes from real traffic, flow reconstruction turns one request_id into a causal chain, and the health summary ranks what is actually broken.
Query — bounded stream scans with cursors and time windows, filters by subject, date, text and JSON event type, saved filters shared across all three surfaces. Binary payloads (protobuf, msgpack) are detected and shown as hex dumps rather than mojibake.
Browse — KV buckets with per-key revision history including deletes, Object Store metadata, and server health from the monitoring port (varz / jsz / connz).
Change — publish, request/reply, purge, and delete messages, consumers and streams, from the UI and the CLI, behind confirmation. Never from the agent surface.
Integrate — read-only HTTP API under /api/integration, bearer tokens with per-token audit identity, and POST /api/integration/enrich/sentry to attach NATS context to an error without exposing credentials.
Full list in docs/features.md · CLI reference in docs/cli.md.
Credentials live in contexts stored locally under data/ (git-ignored). The UI never holds the NATS connection — it always goes through the bridge, which pools one connection per context.
The server binds to 127.0.0.1 by default because /api/contexts and /api/connect are unauthenticated local endpoints. To expose the Integration API and the WebSocket, configure bearer tokens with NATS_TRAIL_TOKENS=name:token or data/tokens.json; audit entries then record the authenticated token name per call.
A shared deployment has no built-in login on purpose: identity comes from whatever fronts the service (an ingress with OIDC, oauth2-proxy, Cloudflare Access, Teleport or network isolation), so no passwords are stored here. Contexts declared through NATS_TRAIL_CONFIG resolve ${VAR} from the environment and cannot be edited or deleted through the API.
Tracked in docs/roadmap.md.
Phases 0–3 are complete. npm release · KV and Object Store browsing · server health · binary payload handling · nkey auth · subject discovery · flow reconstruction · health summary · incident enrichment for Sentry, Grafana, Datadog and PagerDuty · stream, consumer and KV administration · MCP registry listing · indexed correlation search · declarative config and a Helm chart. All writes are human-only, behind scoped tokens and audited with their arguments.
Next: cluster awareness, deliberately deferred rather than pending work.
Deliberately out — protobuf and msgpack *field* decoding (needs a per-subject schema registry) and competing with NUI on GUI breadth. See docs/roadmap.md.
Planned, not started: for teams that explicitly want agent wri
ตัดมาแค่ช่วงต้น อ่านต่อใน repo