Spec Driven Development
by formulahendry
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Runs on your computer★ 440MITUpdated 14 months ago
Install
Tracewatch
Overview
Description from the maker (original English)
Observability, tracking, and root-cause for Security Wave scans and findings.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiNot measured yet★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Other
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- The registry lists no key to fill in.
You need
- npmNode.js installed (for the npx command)
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": {
"tracewatch": {
"command": "npx",
"args": [
"-y",
"@reneturcios/tracewatch",
"mcp"
]
}
}
}Run this in your terminal
claude mcp add tracewatch -- npx -y @reneturcios/tracewatch mcpOr copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"tracewatch": {
"command": "npx",
"args": [
"-y",
"@reneturcios/tracewatch",
"mcp"
]
}
}
}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.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"tracewatch": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@reneturcios/tracewatch",
"mcp"
]
}
}
}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.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
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
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account CloudCorpRecords, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Otheri
- More stars than 0% of the other 32435 servers in this category
- Published to the registry more recently than 75% of the other 32435 servers in this category
- Basic checks equal to or better than 100% of the other 32435 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Tracewatch safe?
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.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
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).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.2.2) reached the registry 11 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js, Docker on your computer.
What can I use instead?
In the same category: Spec Driven Development, Remote Desktop Commander, Apify MCP Server
Alternatives
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
Remote Desktop Commander
by desktop-commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Runs in the cloud★ 211Updated yesterday
Install
Apify MCP Server
by apify
Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡
Runs in the cloudUpdated today
Install
README from the maker
Open the README
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.
tracewatch
Observability, tracking, and root-cause for the Security Wave.
The Security Wave tools (hookcheck, actionpin, injectcheck, mcpvet, depguard, flowcheck) answer "what is wrong right now, in this one scan." tracewatch is the wave's memory and stopwatch. It ingests their JSON reports over time and answers the questions an incident actually turns on:
- What changed since the last scan? Did a pin silently regress to a mutable tag? Did the ref under an already-pinned action move? That move is the tj-actions shape from March 2025: a tag retargeted under every repo that trusted it, invisible to anyone who only ever ran one scan.
- Where did this finding come from? tracewatch blames a finding to the commit that introduced it (git pickaxe on the finding's own content) and to the pull request that carried it, and labels every statement confirmed, inferred, or not established.
- How fast do we notice? Watch mode scans new issues, PRs, files, and tree changes on arrival and records time-to-detect for each one, so "early detection" is a measured number. The comparison point matters: hosted AI firewalls detect at prompt time, after the agent has already read the content. tracewatch detects at rest and on arrival, before any agent session exists.
- Is the estate getting better? Verdict trends, open findings by tool and severity, mean time open for resolved findings, and detection latency stats, per repo, over the whole scan history.
Deterministic, offline-first, local store you can grep. No hosted backend, no account, no telemetry.
Install
npx -y @reneturcios/tracewatch --versionnpm install -g @reneturcios/tracewatch docker run -i --rm ghcr.io/cloudcorprecords/tracewatch mcp
Quick start
# scan a repo with all six tools and start tracking ittracewatch ingest ~/src/myrepo
what changed since the previous scan?
tracewatch diff myrepo
where did this finding come from?
tracewatch blame myrepo --finding tw_0123456789abcdef
health over time
tracewatch report myrepo
watch a directory and scan new content on arrival
tracewatch watch ~/src/myrepo --interval 30
What it tracks
Every ingest stores one scan record (timestamp, tool versions, verdicts, git HEAD) plus one observation per finding. Findings carry stable IDs: a hash of tool, rule, normalized location, and a content signature. The same finding keeps its identity across scans and tool versions; a content edit keeps the identity and changes the ID version, which is what diff reports as CHANGED.
Diff groups: NEW, RESOLVED, CHANGED (with field-level old to new), verdict moves, and REF EVENTS. A ref event fires whenever an action's ref or classification moves, with both values spelled out:
- pin-regression: PINNED to MUTABLE or BRANCH
- pin-improvement: MUTABLE or BRANCH to PINNED
- ref-move: the ref changed inside one classification (for a pinned action, the SHA itself moved)
Blame (root cause)
tracewatch blame myrepo --rule CURL-PIPE-SH --file package.jsontracewatch blame myrepo --finding tw_0123456789abcdef --json
Evidence is labeled, never blended:
- CONFIRMED: the introducing commit from
git log -Son the finding's needle in your local clone; the current-line commit fromgit blame; the PR association from the GitHub API (commits/{sha}/pulls) when the clone has a GitHub remote; ref history and first/last seen from the store itself. - INFERRED: circumstantial statements, written as inferences (for example, when the introducing commit and the current-line commit differ, the line was rewritten later without introducing the content).
- NOT ESTABLISHED: whatever could not be proven, with the reason (no clone recorded, no GitHub remote, API unreachable). Provenance is never guessed to fill the page.
Watch and time-to-detect
tracewatch watch ~/src/myrepo --interval 60 --alerts alerts.jsonltracewatch watch owner/repo --path ~/src/myrepo-clone --interval 60
Local mode polls a directory: new or changed text files are scanned with injectcheck the poll they appear in; a git HEAD move triggers a full ingest plus diff. GitHub mode polls an owner/repo slug: new issues and PRs are scanned on arrival, HEAD moves are recorded (and scanned when you pass a local clone with --path). Every detection writes a record with time-to-detect = detection time minus the content's own creation time (issue created_at, commit time, file birth time). State checkpoints after every cycle, so a restarted watch resumes without re-alerting history. Alerts stream as JSONL to stdout and to the --alerts file.
Polling is the portable fallback. The fastest path is event-driven, in CI:
name: tracewatch-issueson: issues: types: [opened, edited] pull_request: types: [opened, edited, synchronize] permissions: contents: read jobs: scan-new-content: runs-on: ubuntu-latest steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4 with: node-version: 24
- name: Scan the new issue or PR body on arrival env: BODY: ${{ github.event.issue.body || github.event.pull_request.body }} run: | printf '%s' "$BODY" > /tmp/body.md npx -y @reneturcios/injectcheck file /tmp/body.md --json > /tmp/report.json npx -y @reneturcios/tracewatch import ${{ github.repository }} --report injectcheck=/tmp/report.json
Known limit, stated plainly: GitHub watch mode reads through the local ghapi helper, whose output truncates long responses; an issue poll that cannot be parsed in full is logged as a watch note and retried next cycle rather than partially trusted. The CI pattern above has no such limit and is the recommended production path for issue scanning.
Reports
tracewatch report myrepo # humantracewatch report myrepo --json # machine tracewatch findings myrepo --tool hookcheck --status open
The health report carries the verdict trend across every scan, open findings by tool and severity, resolved count, mean time open for resolved findings (first-seen scan to the scan where the finding disappeared), all ref events, and detection latency stats (count, median, max, by kind).
MCP
tracewatch mcp serves a stdio MCP server with seven tools:
| Tool | What it does |
|---|---|
| ingest_scan | Run the six tools on a local path and store the scan |
| diff_scans | NEW / RESOLVED / CHANGED, verdict moves, ref events between two scans |
| finding_provenance | Introducing commit, current-line commit, PR, ref history for one finding |
| repo_health | Verdict trend, open findings, mean time open, detection latency |
| watch_status | Every tracked repo: scans, last scan, open findings, median TTD |
| list_findings | Tracked findings filtered by tool, severity, status |
| explain_finding | The full evidence bundle for one finding, written to act on |
Store
Append-only JSONL under ~/.tracewatch (override with --store or TRACEWATCH_STORE): scans.jsonl, findings.jsonl, detections.jsonl, alerts.jsonl, plus watch-state.json checkpoints. Plain text on purpose. Finding status is derived from the observation series on every read, never stored as mutable state, so the store cannot disagree with itself. Identical store state always renders identical diff and report output.
Exit codes: 0 success or no changes, 1 a diff found changes, 2 usage error or total failure, 141 the reader closed the output pipe before the report was delivered.
Honesty rules
- A verdict is a scan result, never a safety claim. tracewatch reports what the six tools found and when; it does not certify a repo clean.
- Time-to-detect is measured against the content's own timestamps and recorded per detection; the report shows the distribution, not a best case.
- Blame separates confirmed evidence from inference and says "not established" out loud.
depguard scope note
depguard findings only exist relative to a comparison: a dependency was added, removed, or changed against a base. tracewatch preserves that context end to end. Every depguard finding carries the base (a git ref, a directory path, or none), the head path, the run mode, and its per-finding change kind and version move, and the scan record carries the same context at scan level, so a diff can say what changed against what.
Direct-run ingest (tracewatch ingest) runs depguard in its offline snapshot mode against the bare target, which surfaces manifest and lockfile findings (including typosquat suspects) with base recorded as none. A full base/head comparison needs a base the bare target does not name: run depguard with --base or --base-path yourself and import the report (tracewatch import --report depguard= ), and the diff context lands in the store with the findings.
MIT. Part of the Security Wave: hookcheck (persistence hooks), actionpin (Actions pinning), injectcheck (prompt injection in agent-read content), mcpvet (MCP server and skill vetting), depguard (dependency change guard), flowcheck (workflow permission hardening), tracewatch (observability and root cause).