Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Composable skill packets, harvests, workflow routing, and release/audit rubrics over MCP.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Die .mcpb-Datei des Entwicklers herunterladen
Der Link führt zur Datei des Entwicklers selbst; wir hosten sie nicht und verpacken sie nicht neu. Öffne die Datei, dann installiert Claude Desktop sie.
Führe das in deinem Terminal aus
Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto jakyeamos bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.5.4) kam vor 4 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du MCPB auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, EmbeddedCI BenchPod
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
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.
Drive a BenchPod hardware-in-the-loop bench: power, flash, UART, I2C, CAN, analog and logic.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
TMCP Slash commands are manual imports. TMCP is the compiler.
TMCP turns scattered agent instructions into task-specific operating packets. The user describes the work in natural language. TMCP infers task identity, compiles the strongest current packet from skills/rules/evidence, recompiles as the work changes, and leaves an audit trail.
Skill names are provenance, not the user interface. Power users can still force a route; the default is natural prompting.
TMCP runs standalone from a repo checkout, copied plugin package, Codex plugin cache, Claude plugin cache, or any MCP host that can launch the bundled Node entrypoint. The former AIOS adapter is deprecated and disabled by default; AIOS_ROOT alone no longer enables it.
See docs/ADAPTIVE_PACKET_RUNTIME.md for the adaptive packet runtime design.
From a TMCP checkout or plugin root:
node scripts/tmcp_launcher.mjs doctor
node scripts/tmcp_launcher.mjs status node scripts/tmcp_launcher.mjs compose-packet "Improve this agent run" --project-path . --phase start node scripts/tmcp_launcher.mjs harvest skills --limit 5 --no-write-artifacts node scripts/tmcp_launcher.mjs recommend skills --candidate-workflows release_readiness --candidate-workflows developer_experience --min-confidence 0.1 --compose --no-write-artifacts
With no arguments, the same launcher starts the MCP stdio server:
node scripts/tmcp_launcher.mjs
skills/tmcp into a skills directory. Use the skill for routing and manual packet synthesis unless the host also exposes the bundled launcher.node scripts/tmcp_launcher.mjs doctor from the checkout root.scripts/tmcp_launcher.mjs from the plugin root.scripts/tmcp_runtime.mjs so all agent hosts use one pinned active release with offline rollback. See Central runtime.TMCP_ENABLE_DEPRECATED_AIOS_ADAPTER=1 and AIOS_ROOT; new installations should use standalone TMCP.Claude Desktop users can add the launcher as a local stdio MCP server. See docs/CLAUDE_DESKTOP.md.
TMCP labels three independent surfaces:
tmcp, skill-harvest, workflow-recommendation, release-readiness, and dx-audit are stable routing packages.release-readiness and dx-audit are the stable templates in the recommendation catalog.doctor, status, explain, compose-packet, and runtime-next are stable. Harvest, evaluation, recommendation, promotion, receipt, and expert-rubric tools remain experimental.Experimental templates and tools remain shipped and callable. They are labeled experimental in their own outputs and frontmatter so users do not confuse a stable package route with a stable tool contract or curated template.
Experimental workflows include UI rubric, security/privacy, test strategy, adaptive workflow pack, custom rubric generation, routing policy, skill gap analysis, incident postmortem, architecture decision, migration readiness, agent handoff, PR risk, performance readiness, data integrity, public-sector readiness, and repo behavior spec loop.
| Tool | Purpose |
|---|---|
tmcp_doctor | Check first-run readiness and supported install layouts. |
tmcp_status | Report standalone capability and optional AIOS adapter status. |
tmcp_explain | Compile a task-specific TMCP packet. |
tmcp_compose_packet | Compile a task/phase operating packet with task_identity, packet_markdown, and provenance. |
tmcp_runtime_next | Return packet deltas or a full recompiled packet (output_mode: full) after runtime evidence changes. |
tmcp_record_receipt | Write an advisory run receipt after verification or outcome on a secure-persistence host. |
tmcp_harvest_skills | Harvest local skills, instructions, rules, docs, and workflows into source nodes. |
tmcp_evaluate_skills | Create or score a skill-evaluation plan from full SKILL.md inputs. |
tmcp_recommend_workflows | Recommend stable or experimental workflows from harvested evidence, with stability metadata. |
tmcp_promote_harvest | Explicitly promote reviewed harvest signals into durable source-to-atom and atom-to-workflow graph artifacts. |
expert_rubric_review_plan | Produce an expertise packet, scored rubric, evidence audit, remediation plan, and verification expectations. |
Harvest redacts sensitive-looking values and secret-like provenance paths by default and treats harvested instructions as untrusted text. Default harvest behavior excludes .env*, credentials, tokens, browser profiles, private caches, dependency trees, build outputs, VCS data, and generated TMCP/AIOS artifacts. It does not follow source symlinks unless follow_symlinks is explicitly enabled; enabled links must still resolve inside the selected source root.
On hosts with secure descriptor-relative filesystem operations, harvest artifacts are written as one staged, atomic bundle through a symlink-safe destination. Leave output_dir unset for a unique .tmcp/harvest-* directory, or provide an output directory that is new or empty.
Skill evaluation accepts explicit regular SKILL.md inputs, can confine them to a supplied project root, and redacts source, plan, and evidence values before deriving reports. Its initial plan artifact is a staged bundle in a new or empty directory; evidence scoring may safely add its report to that same directory.
Artifact persistence is deliberately unavailable where those secure filesystem operations do not exist. doctor and status report the capability; use --no-write-artifacts for portable analysis and see Compatibility for the boundary.
tmcp_record_receipt has no non-persisting preview because the receipt is the artifact itself. Run it only when status reports artifact persistence available.
Packet sessions are equally explicit: compose-packet --session-id writes one redacted, project-local latest-packet record only when secure persistence is available. They are for a single serialized run, not a global history or coordination service. See the CLI session contract.
If a harvested source tries to override system, developer, or user instructions, TMCP reports a warning. See SECURITY.md.
Harvest a local skills folder:
node scripts/tmcp_launcher.mjs harvest ./skills --objective "Harvest reusable skill behavior" --limit 20 --no-write-artifacts
Recommend workflows for a project:
node scripts/tmcp_launcher.mjs recommend . --candidate-workflows release_readiness --candidate-workflows developer_experience --min-confidence 0.1 --compose --no-write-artifacts
Compose a current-task packet and recompile during the run. This session flow requires status to report artifact persistence available:
node scripts/tmcp_launcher.mjs compose-packet \
"Redesign these pages. Make them visually striking, interactive, modern, motion-rich, and production-ready." \ --project-path "$PWD" --phase start --session-id redesign-run
node scripts/tmcp_launcher.mjs recompile-packet \ "Redesign these pages..." \ --project-path "$PWD" \ --current-phase runtime \ --session-id redesign-run \ --files-changed app/page.tsx
node scripts/tmcp_launcher.mjs record-receipt packet-123 --activated-atoms ui-browser-verification --outcome passed
When session persistence is unavailable, preserve the compatibility path by passing the prior composed JSON inline through --previous-packet instead.
Legacy delta-only runtime routing:
node scripts/tmcp_launcher.mjs compose-packet "Fix the dashboard UI bug" --project-path . --phase start
node scripts/tmcp_launcher.mjs runtime-next "Fix the dashboard UI bug" --current-phase verification --files-changed app/page.tsx --failures "vitest failed" node scripts/tmcp_launcher.mjs record-receipt packet-123 --activated-atoms ui-browser-verification --outcome passed
Promote reviewed harvest signals into durable routing artifacts:
node scripts/tmcp_launcher.mjs promote-harvest . --selected-workflows release_readiness_workflow --output-dir .tmcp/promoted-harvests/release-readiness
On secure-persistence hosts, promotions also persist a redacted advisory graph under TMCP_HOME/promoted-harvests/ /, or ~/.tmcp/promoted-harvests/ / when TMCP_HOME is unset. Receipts live under TMCP_HOME/receipts/ /. Global cache content is advisory and cannot override system, developer, user, or project instructions. Packet composition and runtime routing do not read that cache unless the caller explicitly passes --cache-policy global; their default policy is none.
Run an expert rubric review from evidence snippets:
node scripts/tmcp_launcher.mjs review-plan "Review release portability" \
--project-path . \ --evidence-json '[{"dimension_id":"source_grounding","severity":"warning","summary":"Release claims need fresh package evidence.","evidence":["python3 scripts/check_release_package.py ."],"recommended_fix":"Run and cite the release package check before publishing."}]' \ --no-write-artifacts
More examples live in examples. Developer onboarding and release readiness exercise stable curated templates; skill-harvest and recommendation examples remain available through experimental tool contracts.
Before release:
python3 -m unittest discover -s tests
python3 scripts/release_package_compile.py . node --check scripts/tmcp_launcher.mjs python3 scripts/check_contracts.py . python3 scripts/check_install.py . python3 scripts/check_release_package.py . --verify-reproducible
The release package check builds from a clean, reviewed Git revision rather than the working directory. It ships only an explicit allowlist of committed files, rejects unsafe paths, symlinks, and secret-like content, then emits a deterministic RELEASE_MANIFEST.json plus archive digest. The CI release gate repeats the build from the same Git tree and requires both digests to match. It also validates frontmatter, hardcoded local paths, private example names, links, extracted-package install shape, doctor, sample harvest, sample workflow recommendation, sample expert rubric planning, composition/runtime/receipt smoke coverage, and stable/experimental workflow labeling. It is a DOI blocker until existing absolute user paths in release evidence docs are redacted or normalized.
TMCP is prepared as an independent software-methods artifact. See RESEARCH_READY.md and docs/release-notes/v0.3.3-doi.md for the citable artifact boundary, validation path, data-availability policy, and claim limits.