Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Runs a command, keeps every byte on disk, returns only the lines that matter
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
NVIDIA_API_KEYLos valores marcados como secretos son llaves de tu cuenta. Nunca los compartas ni los pegues en un chat.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json
{
"mcpServers": {
"sift": {
"command": "uvx",
"args": [
"sift-cli",
"mcp"
],
"env": {
"NVIDIA_API_KEY": "your-value"
}
}
}
}Ejecuta esto en tu terminal
claude mcp add sift --env NVIDIA_API_KEY=your-value -- uvx sift-cli mcpCompleta los valores vacíos antes de ejecutarlo.
Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"sift": {
"command": "uvx",
"args": [
"sift-cli",
"mcp"
],
"env": {
"NVIDIA_API_KEY": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"sift": {
"type": "stdio",
"command": "uvx",
"args": [
"sift-cli",
"mcp"
],
"env": {
"NVIDIA_API_KEY": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 7 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub slymnysr, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
Debes completar: NVIDIA_API_KEY
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (1.1.0) llegó al registro hace 2 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Python (uv) en tu computadora.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, SuperCollider
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
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.
Make sound with SuperCollider: synths, drums, chords, melodies and soundscapes over OSC.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
Runs your command, then gives the model only the lines that matter.
A test suite prints 4,000 lines and eleven of them are the failure. A build prints a progress bar that redraws 900 times. An install lists every package it touched. All of it lands in the context window, and — this is the part that costs — it is re-sent in full on every turn that follows.
sift is an MCP server and a command line for that problem. It runs the command itself, keeps every byte on disk, and hands the model a view: the failures, the summary, the lines a reader would actually stop on. The rest is marked, not deleted.
Two numbers, both measured, both reproducible from this repository. Running this project's own test suite prints 652 lines — 21,392 tokens, as the model's own tokenizer counts them. What comes back is 8 lines and 208 tokens: 99% fewer (python test/kazanc.py). Removing almost everything is the easy half. Over a 22-sample corpus of real build and test output, the default budget keeps 138 of the 140 lines a reader could not do without (python test/budget.py).
$ sift run -- pytest
FAILED test/test_auth.py::test_expired_token - assert 401 == 200 ... ─ 3,914 lines not shown · sift peek 9f2c41ab for any of them ─ === 1 failed, 212 passed in 18.4s ===
A file you did not produce — a log, a saved CI transcript, a crash dump — gets the same treatment without being run:
$ sift digest ci-run-8812.log
2026-09-02T04:11:07 Building 214 targets ─ 38,904 lines not shown · sift peek ci-run-8812.log for any of them ─ ERROR: //src/parser:parse_test failed in 4.1s ─ 1,022 lines not shown · sift peek ci-run-8812.log for any of them ─ FAILED: 1 of 214 targets
A list is not read in lines. A JSON array written for a machine often has no newlines at all, and there is nothing in a line of one worth choosing, so the record becomes the unit and the same rules hold:
$ sift digest export.json
{"id": 3, "status": "failed", "error": "connection refused"} ─ 412 records not shown · sift peek export.json for the text they came from ─ {"id": 416, "status": "ok"}
The same question, asked about source code instead, is a table of contents:
$ sift outline src/parser.rs
pub struct Parser { pub fn parse(input: &str) -> Result { ─ 34 lines not shown · sift peek src/parser.rs for any of them ─ impl Iterator for Tokens {
And a command that does not end — a dev server, a log tail, a build you want to keep working during — is started and then read a slice at a time:
$ sift run --background -- cargo build --release
9f2c41ab $ sift follow 9f2c41ab warning: unused import: std::fmt ─ 212 lines not shown · sift peek 9f2c41ab for any of them ─ error[E0308]: mismatched types sift 9f2c41ab · running · new lines 1-247 · 2 shown · nemotron $ sift follow 9f2c41ab # only what has arrived since $ sift follow --all --wait 30 # every run at once, holding for something new $ sift stop 9f2c41ab # ends it, and everything it started
Nothing is shown twice, and the numbers are the run's own: line 247 stays line 247 in sift peek for as long as the capture exists.
A free model does. sift sends it the numbered lines and asks one question: *which numbers matter?* It answers with numbers, and nothing else it says is used — the text you read above is printed from the local capture, byte for byte.
That is the whole trick, and it is why this is not a summariser. A summariser can be wrong about what a line said. sift cannot be: it never writes a line, it only chooses one.
It also means language coverage is not a list. A model reads Turkish, Japanese, Arabic and Hindi; it reads Rust, COBOL, Mojo and a language released last week. Nothing here enumerates them, so nothing here can be missing one.
Nothing shown is invented. The judge returns line numbers. Text always comes from the local file.
Nothing is thrown away. sift peek returns the raw capture, unchanged. Every gap in a view says how many lines it covers.
Nothing can break your command. No API key, no network, an overloaded endpoint, a nonsense reply, a bug in the distiller, or a decision that nothing may leave this machine — every one of these falls back to rules that need none of them. The command still runs; you still get its output; you get its exit code.
One thing: the text of a question. Before it is sent, anything credential-shaped is replaced — tokens with a known prefix, JWTs, authorization headers, passwords in connection strings, the body of a PEM block.
That costs you nothing to read. The model is only ever asked for line numbers, and the lines are printed from your own file, so a line masked on the way out is still shown to you in full.
Three switches:
SIFT_MAX_CAPTURE=0 # keep everything a command writes, however much that is
SIFT_BASE_URL=... # ask your own endpoint instead, and no key is wanted SIFT_MODELS=a,b # which models to ask there, best first SIFT_NO_MODEL=1 # never send anything; use the deterministic view SIFT_MASK=0 # send unmasked SIFT_CACHE=0 # ask again, even about text already answered SIFT_EFFORT=low # let the model think less, and lose some of what matters SIFT_PATIENCE=0 # one quick pass only; do not wait out a busy hour
Masking is not complete and does not claim to be: a bare secret shaped like nothing in particular gets through. SIFT_NO_MODEL is the one that guarantees.
The fourth is a measured trade and is off by default. Asked which lines matter in a 404-line build, the model writes about 900 tokens of reasoning to produce a twelve-token answer, and you wait 15 seconds for it. At SIFT_EFFORT=low the same question takes 2.4 seconds — and over the corpus it loses 7.8% of the lines a reader could not do without, in exactly the places this tool exists for: a mainframe job's return code, a crash loop's diagnosis. Speed is available; it is not the default, and the price is written down.
The third is about not paying twice. An answer already given for exactly these bytes and exactly this question is used again instead of bought again — and what is kept is the numbers, never the view, so the text is still rendered from your own file and the gap still names your own capture. A view that cost no request says (remembered) where it would otherwise name the model.
Captured bytes never leave $SIFT_HOME (~/.cache/sift by default). Nothing is uploaded, nothing is logged elsewhere, and removing a capture directory removes everything that was ever kept about it.
One capture keeps at most a gigabyte. That is far past any real build log and a few seconds of a command stuck in a loop, which is the case it exists for: nothing is thrown away, and the disk somebody else needs is not filled either. Reading never stops — a pipe nobody drains would stop the command, and that is the one thing this will not do — so the command finishes, its exit code is its own, and the footer says kept the first 1,073,741,824 bytes of it rather than letting you believe you have the whole run. SIFT_MAX_CAPTURE=0 turns the ceiling off for anyone who would rather have the disk.
They also never go away on their own. Nothing here sweeps, expires or tidies in the background: sift gc [DAYS] is the only thing that deletes a capture, and it deletes when you type it and not before. What it leaves is one line per handle — when it went and how big it was, never the command — so that a gap marker read a fortnight later gets *"removed on the 8th"* instead of the answer it would give for a handle you made up.
sift run [--timeout SECONDS] [--shell] [--background] [--cwd DIR]
[--budget LINES] [--keep PATTERN] [--] COMMAND... sift follow [HANDLE] [--all] [--wait N] what a background run has said since you last looked sift stop [HANDLE] end it, and everything it started sift outline PATH|- what a file declares, without its bodies sift digest PATH...|- what is in files somebody else produced sift peek HANDLE|PATH [FIRST] [LAST] sift hook answer one shell-command event on stdin sift mcp speak the protocol on stdin, for a client sift tools which dense tools this machine has sift tool NAME [ARGS...] run one of them, distilled sift memory [TERM] what has been run here before, and how it went sift list [COUNT] what is running, and what has been run sift stats [COUNT] what the shortening cost, and what it saved sift gc [DAYS] remove captures older than that, and say what went
A path of - reads standard input, which is the other way somebody else's output turns up:
$ journalctl -u nginx --since yesterday | sift digest -
Sep 08 04:11:07 nginx[2114]: worker process 2119 exited on signal 11 ─ 8,204 lines not shown · sift peek 7c1a04e9 for any of them ─ Sep 09 01:02:55 nginx[2114]: signal 15 (SIGTERM) received, exiting
What arrives on a pipe has no path anybody could type again, so it is kept as a capture of its own and the gap marker names that instead. The second rule is why: a view that left lines out and pointed at a scratch file would be pointing at nothing by the time somebody read it.
Several paths given to digest are asked about at the same time, and --all follows every running command in one go. Both are the same idea: the waiting is the cost, so do it once. --wait N holds until a run actually says something instead of answering that nothing has happened yet.
sift hook is the way to catch the shell commands a client runs on its own, without a proxy: point the client's pre-tool hook at it and every shell command comes here first. Everything is routed — nothing here guesses which commands are worth catching, because a list of those is a list of tools in disguise and how much a command prints is not knowable before it runs. Routing everything costs nothing: a view of twelve lines is twelve lines. It fails open, so a bug in it leaves your shell exactly as it was, and SIFT_HOOK=0 switches it off.
It is the part of this that pays most and the only part you have to turn on, so it offers itself rather than waiting to be found:
sift hook --install # says what it gives and what it costs, then asks
sift hook --uninstall # and takes it back out
It writes one line into your client's settings, keeps a copy of the file as it was, and touches nothing else that is in there. sift run mentions it once, ever, and then stops.
sift tool runs one of three programs that answer a question *without opening the file* — sg (ast-grep) for structural search, diff (difftastic) for a diff that can tell a reindent from a change, loc (scc) for the size of a tree. Their output is large by nature, which is exactly why they belong here. No binaries ship with this package: sift tools says which of them this machine has and what each is called, and installing one stays your decision.
sift memory asks no model at all. The question is counting — how often, how it went, which command has never once worked here — and a model asked to count is slower, costs a request and is sometimes wrong. The model decides what cannot be computed, and nothing else.
sift stats says what the shortening saved and what it cost, and keeps those apart because they are not the same kind of number. The share is this tool's own arithmetic over bytes it holds, so it is exact. The cost is the endpoint's count of its own tokens, so it is measured. And beside it now sits the number the question is really about — what the output weighed, counted by the same tokenizer at the moment it was sent:
$ sift stats
handle captured shown part asks weighed cost command 9f2c41ab 62,003 B 450 B 0.7% 1 21,392 5,120 pytest -v
1 run · 62,003 B ca
Solo se muestra el principio; lee el resto en el repo