Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Hypothesis-driven problem solving for AI agents: probe, falsify, escalate.
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": {
"inquisitor": {
"command": "uvx",
"args": [
"inquisitor-mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add inquisitor -- uvx inquisitor-mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"inquisitor": {
"command": "uvx",
"args": [
"inquisitor-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": {
"inquisitor": {
"type": "stdio",
"command": "uvx",
"args": [
"inquisitor-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 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto iamalisson 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.2.3) kam vor 3 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, Recta
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.
Cheaper cross-chain stablecoin routes for AI agents; 5 % of the verified saving, nothing if none.
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.
Hypothesis-driven problem solving for AI agents Probe · Falsify · Escalate — never overcomplicate, never blind-retry
inquisitor makes AI agents solve problems the way a chess engine plays chess: it cannot explore every branch, so it estimates complexity first, prunes paths that add no information, and spends its search budget only where the problem actually is.
It ships as two coordinated layers:
inquisitor-mcp) — the engine. Web search, project analysis, code tracing, project scaffolding, and a persistent investigation state machine. Works with any MCP-compatible agent: OpenCode, Claude Code, Claude Desktop, Cursor.skills/inquisitor/SKILL.md) — the behavioral layer. Injects the probe-and-gate loop, the pruning rules, and the full methodology into the agent's reasoning.The method is not invented here — it is assembled from primary sources: Newton's Analysis→Synthesis skeleton, hardened with the scientific method's own defenses against wrong assumptions (falsification, strong inference, competing-hypotheses analysis, anti-fixation reframes, pre-mortems) and constrained by engineering discipline (NASA/JPL's Power of Ten, surgical-change guidelines, the minimalism ladder). Every source is cited in Foundations.
Web search, codebase scans, and code tracing are tools invoked when local evidence is insufficient — never mandatory rituals.
Depth is an output, not a label. An LLM's up-front difficulty guess is its least reliable signal — poorly calibrated, and biased to under-rate exactly the hard problems that matter. So inquisitor never classifies a problem before understanding it: it runs a cheap probe (the single cheapest action that could confirm or kill the best current hypothesis), and the probe's *result* — never the prediction — sets the depth:
flowchart TD
P([Problem]) --> F["FRAME done = ? · must not break = ?"] F --> D{"delegate? a specialist skill owns this"} D -->|yes| SK["hand off — /tdd, /code-review, ..."] D -->|no| PR["PROBE cheapest action that could confirm or kill the best hypothesis"] PR -->|"obvious, local"| SH[" Shallow fix → verify no ceremony "] PR -->|"clear single- component cause"| ST[" Standard frame → minimal evidence → fix → verify"] PR -->|"root cause unknown, multi-component"| DE[" Deep — Newton 7-phase: DEFINE → AXIOMS → ANALYSIS → EXPERIMENT → SYNTHESIS → VALIDATE → QUERY
SH -.->|"gate trigger / failed fix / low confidence"| ST ST -.->|"gate only raises depth — never lowers"| DE
Escalation is enforced, not just allowed. The probe is only a starting point: objective gate triggers (touching infra/deploy/routing/config, auth/security, data migrations, multi-file fixes, prod-only symptoms) force a minimum depth regardless of how "clear" the problem feels, and a 3-question confidence check (read the runtime path? can name the runtime signal? verified the platform assumption?) bumps the depth up per unanswered question. Downgrades need cited evidence, never a feeling. Inflated ceremony is not allowed either — a 7-phase investigation of a typo is as wrong as a blind guess at a race condition.
Retry is never blind. "Loop until it passes" agents (the Ralph-loop pattern) have persistence but no memory: on failure they revert, flush, and re-roll — the same wrong idea, retried with fresh confidence. Inquisitor keeps a failure ledger instead: every dead hypothesis is recorded with the evidence that killed it, every retry must name what is different and why that changes the outcome, and two dead hypotheses from the same family force a *reframe* — re-audit an assumption, invert the question, widen the system boundary — never a third attempt at the same idea. Persistence with memory, creativity on evidence.
Each rule in the method traces to a primary source. The left column is the citation; the right column is the exact mechanism inquisitor takes from it.
| Source | Mechanism adopted |
|---|---|
| Isaac Newton, *Opticks*, Query 31 (1704) | The investigation skeleton: Analysis before Synthesis — define, decompose, experiment, only then reconstruct — and closing with open Queries instead of false certainty. *Hypotheses non fingo.* |
| T.C. Chamberlin, *The Method of Multiple Working Hypotheses*, Science (1890) | Hold at least two rival explanations at all times; a single hypothesis turns every subsequent observation into confirmation. |
| Abraham Luchins, *Mechanization in Problem Solving* (1942) — the Einstellung effect | The failure ledger's trigger: repeating a familiar approach after it stopped working is a measurable fixation, and the cure is a forced reframe, not another attempt. |
| Karl Popper, *The Logic of Scientific Discovery* (1959) | Falsify first: for the leading hypothesis, name the observation that would disprove it and hunt for that observation before anything else. |
| John Platt, *Strong Inference*, Science (1964) | Design the experiment that *excludes* a hypothesis, not the one that corroborates the favorite — discriminating tests over confirming tests. |
| Richards J. Heuer, *Psychology of Intelligence Analysis*, CIA (1999) | Analysis of Competing Hypotheses: rank hypotheses by the evidence *inconsistent* with each — confirming evidence is cheap and usually fits several at once. |
| Gary Klein, *Performing a Project Premortem*, Harvard Business Review (2007) | Before shipping: assume the fix is live and the problem still happens — name the likeliest reason and probe it now. |
| Source | Mechanism adopted |
|---|---|
| Gerard J. Holzmann (NASA/JPL), *The Power of Ten: Rules for Developing Safety-Critical Code* (2006) | The P10 template: a rule set small enough to remember and strict enough to check mechanically. |
| Andrej Karpathy's LLM coding guidelines (2025) | Think before coding · simplicity first · surgical changes · goal-driven execution. |
| Ponytail decision ladder | YAGNI → reuse → stdlib → native platform → installed dependency → one line → minimum code that works. |
Requires uv and Python 3.12+.
inquisitor ships as a Claude Code plugin that installs both the skill and the MCP server — no cloning, no editing absolute paths, no manual symlink.
From within Claude Code, first add the marketplace:
/plugin marketplace add iamalisson/inquisitor
Then install the plugin:
/plugin install inquisitor@inquisitor
That's it. The plugin bundles the inquisitor-mcp server (registered automatically via ${CLAUDE_PLUGIN_ROOT}) and the inquisitor skill. uv syncs the server's dependencies on first launch. Update later with /plugin marketplace update inquisitor.
Prefer to point at a local checkout instead of GitHub?
/plugin marketplace add /path/to/inquisitorworks too.
For OpenCode and Claude Desktop (which don't use Claude Code plugins), or for a manual Claude Code setup, use the steps below.
Option A — no clone (recommended). Once published to PyPI, uvx fetches and runs it on demand — no clone, no absolute paths:
uvx inquisitor-mcp # prints a ready message and waits for a client — Ctrl+C to exit
You'll reference uvx inquisitor-mcp directly in the config below.
Option B — from a checkout (for local development, or before the PyPI release):
git clone https://github.com/iamalisson/inquisitor.git ~/tools/inquisitor
cd ~/tools/inquisitor uv sync
The clone path is up to you — just use the same absolute path in the config below.
~does not expand inside JSON config files, so write the full path (e.g./home/you/tools/inquisitor).
You do not run the server manually. It's a stdio MCP server: your agent spawns and manages it automatically. (If you run it by hand it prints a ready message on stderr and waits silently — that's normal.)
OpenCode — add to ~/.config/opencode/opencode.json (global) or ./opencode.json (per-project):
{
"$schema": "https://opencode.ai/config.json", "mcp": { "inquisitor": { "type": "local", "command": ["uvx", "inquisitor-mcp"], "enabled": true } } }
Claude Code — add to .mcp.json in your project, or ~/.claude.json for all projects:
{
"mcpServers": { "inquisitor": { "command": "uvx", "args": ["inquisitor-mcp"] } } }
Claude Desktop — same mcpServers block in claude_desktop_config.json (Settings → Developer → Edit Config).
Using a checkout instead of
uvx? Swap the command foruvwith args["run", "--directory", "/home/you/tools/inquisitor", "inquisitor-mcp"].
Symlink it so it stays up to date with the repo:
# OpenCode
mkdir -p ~/.config/opencode/skills ln -s /home/you/tools/inquisitor/skills/inquisitor ~/.config/opencode/skills/inquisitor
mkdir -p ~/.claude/skills ln -s /home/you/tools/inquisitor/skills/inquisitor ~/.claude/skills/inquisitor
(Copying the folder works too — you'll just need to re-copy after updates.)
Or, no clone — install just the skill across agents with the skills CLI:
npx skills add iamalisson/inquisitor
(This installs the skill only. For the inquisitor_* tools you still need the MCP server from Steps 1-2 — or use the Claude Code plugin above, which bundles both.)
Config is loaded at startup. Quit and reopen OpenCode / Claude Code, then verify: the inquisitor_* tools appear in the tool list, and the inquisitor skill is available.
| Tool | Purpose | When |
|---|---|---|
inquisitor_search | Multi-backend web search (DuckDuckGo free/keyless, Brave, SearXNG) with content extraction (HTML + PDF) | Local evidence insufficient: unknown errors, unfamiliar libraries, current best practices |
inquisitor_analyze | Project overview: languages, frameworks, tests, deps, git history | Entering an unfamiliar codebase |
inquisitor_trace | Symbol tracing: definition, callers, callees with file:line refs | Bug spans multiple functions/files |
| `inquisitor_phase_ge
Nur der Anfang wird gezeigt; den Rest findest du im Repo