Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Compiler-precise code property graph for C, Python, and TypeScript, navigable 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.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"lachesis": {
"command": "uvx",
"args": [
"lachesis-cpg",
"mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add lachesis -- uvx lachesis-cpg mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"lachesis": {
"command": "uvx",
"args": [
"lachesis-cpg",
"mcp"
]
}
}
}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.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"lachesis": {
"type": "stdio",
"command": "uvx",
"args": [
"lachesis-cpg",
"mcp"
]
}
}
}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 UnboundCompute 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.3) kam vor 2 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv) auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, FlyDocs
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.
Spec-driven development workflow: your agent works issues, sessions and the status lifecycle.
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.
Lachesis reads your code and builds a map of it. Then you can ask the map questions, like who calls this function, where does this value go, and can bad input reach a dangerous spot.
It works on C, Python, and TypeScript/JavaScript, all in one map.
Search tools like grep tell you *where a word shows up* in your code. Lachesis is different. It follows the actual data. It can tell you where a value came from, where it goes next, and whether a request from the outside can reach something dangerous, like a database call with no login check in front of it.
To do this it reads your code the same way a compiler does, not by guessing with text patterns. So it doesn't miss a call just because a name was renamed or imported in a weird way.
You can use it three ways: as a command in your terminal, as a Python library, or as an MCP server that an AI agent can talk to.
Install it, then point it at a folder:
python -m pip install lachesis-cpg
lachesis ./my-project
It builds the map, saves it, and prints the leads. A lead is a spot where outside input can reach something sensitive with no check in the way. Each lead is a question to look into, not a final answer.
✓ compiling (0.7s)
2,677 nodes, 4,539 edges from typescript-compiler-api ✓ finding entrypoints that reach sensitive effects (0.1s)
2 leads (lens=all)
You can also give it a git URL instead of a folder: lachesis https://github.com/owner/repo. It downloads the code to a temp folder, scans it, and cleans up after.
The first scan of a project is slow. After that the map is cached under ~/.lachesis/cache, so every run after is fast.
Terminal. One lachesis command. lachesis ./repo is the easy front door. If you want more control, the steps map to three passes:
lachesis build ./my-project graph.kuzu # step 1: read the code, build the map
lachesis enrich graph.kuzu # step 2: work out the data flow lachesis analyze graph.kuzu --summary # step 3: print the leads lachesis explain graph.kuzu tree.c:1487 # show all the evidence for one spot
Python library. Open the map once, then ask it as many questions as you want.
import lachesis
a = lachesis.Analysis.build("./my-project", "graph.kuzu", enrich=True) leads = a.scan() print(leads.summary())
print(a.explain_sink("tree.c", 1487)) # all the evidence for one spot
Runnable example scripts are in examples/.
MCP (for AI agents). Start the server and an agent can build and query the map on its own:
lachesis mcp ./my-project
See MCP below for setup in Cursor, VS Code, Claude, and Docker.
Once the map is built, these are the moves. They work from the terminal, the Python library, or as MCP tools an agent uses:
| You want to know | The tool |
|---|---|
| What is this part of the code built around? | hubs |
| Where is this name? | search |
| Who calls this? What does it call? | callers, callees |
| Show me the real source | read_body |
| What's in this file or folder? | open_file, open_folder |
| Where does this value go? What feeds this spot? | flow, sources_of |
| Does this input reach that spot? | reaches (gives a path, or a clear no) |
| What does this pointer point at? | points_to, aliases |
| Where does outside input reach something dangerous? | taint |
| Is this C object freed twice, or used after it's freed? | the C lifetime pass |
| Which entrypoints reach sensitive spots with no check? | scan (the leads) |
| All the evidence for one spot, in one call | explain |
Every answer comes with how sure it is. Some links are exact. Some are a safe guess, and Lachesis tells you when it's guessing instead of hiding it. Read the answers as evidence, not as a verdict.
Run lachesis mcp from the same place you built the map. You can hand it a graph.kuzu path, but you don't have to. Start it with no argument and the agent builds its own map when you point it at a repo.
One click (uses uvx, no install step):
Or set it up by hand. If the package is already installed:
{
"mcpServers": { "lachesis": { "command": "lachesis", "args": ["mcp"] } } }
Or let uvx fetch it on first run, no install:
{
"mcpServers": { "lachesis": { "command": "uvx", "args": ["--from", "lachesis-cpg", "lachesis", "mcp"] } } }
Or run it in Docker, with all three languages already in the image:
{
"mcpServers": { "lachesis": { "command": "docker", "args": ["run", "--rm", "-i", "-v", "/path/to/your/project:/src", "ghcr.io/unboundcompute/lachesis:edge"] } } }
More client notes are in docs/queries.md.
Each language is read by a real compiler or its own parser, never a text guess.
| Language | Read with | File types |
|---|---|---|
| TypeScript / JavaScript | the TypeScript compiler | .ts .tsx .mts .cts .js .jsx |
| Python | Python's own ast + symtable | .py .pyi |
| C | Clang | .c .h |
A mixed project is one map, not three. A Python function and a TypeScript function it calls sit in the same map, and the same tools work across both.
Two limits worth knowing. Python has no type checker, so it matches attribute calls by name. C reads one file at a time, so it won't follow a call through a function-pointer table it never sees. Each language says what it can and can't do.
Lachesis works in three steps, and each one is a command.
There's also a C lifetime pass. Some bugs, like freeing the same object twice or using it after it's freed, aren't about one spot. They're about the whole life of an object. A separate pass tracks each C object being allocated, freed, and used, and reports double-free and use-after-free with a path showing how it happens.
The map is saved as a folder (graph.kuzu). It holds an embedded database plus a small index file. That folder *is* the map. Every tool reads it directly.
More detail is in docs/graph-model.md (what's in the map) and docs/scaling.md (big repos, memory, and speed).
python -m pip install lachesis-cpg
Works on Python 3.10–3.12. Python analysis needs nothing extra. Scanning TypeScript/JavaScript needs node on your PATH, and C needs clang. If one is missing you get a clear message, not a crash.
To work from a clone (for contributors):
git clone https://github.com/UnboundCompute/lachesis && cd lachesis
python -m pip install --upgrade pip python -m pip install -e ".[dev]" npm ci cargo build --release --manifest-path native/clang_frontend/Cargo.toml
examples/: a five-minute walkthrough plus a runnable script per feature.docs/graph-model.md: what's in the map.docs/queries.md: every way to ask a question.docs/scaling.md: big repos, memory, and CI.Done recently:
https://…, it downloads, scans, and cleans up.Coming next:
Lachesis is early and moving fast. The map, the storage, the navigation and MCP tools, and the C lifetime pass all work today and are checked by a test suite. The lifetime pass is C-only for now and works within one function. One known false alarm is tracked. The tools may still change before 1.0; the CHANGELOG lists changes.
AGPL-3.0. See LICENSE. You can use, study, change, and share it, including for commercial use. If you run a changed version as a network service, you have to share your changed source with its users. If that doesn't fit your case, a separate commercial license may be an option. See CONTRIBUTING.md or open an issue.
Found a security bug? Please don't open a public issue. See SECURITY.md for how to report it privately.