Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Offline analyzers that find and fix intent-hiding, slow or noisy F#, including agent-written code.
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.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"fsharp-refactor": {
"command": "dnx",
"args": [
"fsharp-refactor",
"--yes",
"--mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add fsharp-refactor -- dnx fsharp-refactor --yes --mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"fsharp-refactor": {
"command": "dnx",
"args": [
"fsharp-refactor",
"--yes",
"--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": {
"fsharp-refactor": {
"type": "stdio",
"command": "dnx",
"args": [
"fsharp-refactor",
"--yes",
"--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 Thorium 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.8.45) kam vor 23 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du .NET auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, debuff
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.
Let coding agents play, test and tune your 2D web game: live state, explained errors, replays, fuzz.
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.
Let's remove parentheses from the internet
Functional refactoring suggestions for F#. The tool clarifies the (agent-generated or old) code's intent, reduces non-alphanumeric noise, and uses built-in .NET libraries more efficiently.
Suggestions are Hint severity: they mark an opportunity, not a defect, and never gate your build.
This project is the big brother of CSharp.Refactor
The tool is fully offline: AI has been used to make it, but it doesn't use AI.
Nothing to configure - the tool reads your project, reports what it would change, and only edits when you tell it to:
dotnet tool install --global fsharp-refactor
fsharp-refactor Your.fsproj --dry-run --api-changes
That prints every fix it would make, with file and position, and writes nothing. When the list looks right, drop the flag to apply them:
fsharp-refactor Your.fsproj --api-changes
It refuses a compilation that does not already build, and fails loudly if applying ever introduces an error.
If you don't want change public methods / API, drop --api-changes:
fsharp-refactor Your.fsproj
Using the tool: Point it at whatever you have - the kind is read off the path:
Your.fsproj | one project |
Thing.fs | one source file - its project is found and analysed, but only that file is edited |
build.fsx | one script - no MSBuild step at all, so it starts instantly. A script with unresolvable references is not refused: the syntactic rules still run over it (an fsi-run script may reference things only the run supplies) |
Your.sln, Your.slnx | every F# project the solution lists |
src/ | the solution in that directory, or the projects beneath it |
"src/**/*.fsproj" | everything the glob matches |
Examples:
| Before | After | |||||
|---|---|---|---|---|---|---|
| Correctness | let s = new FileStream(p, m) | use s = new FileStream(p, m) | ||||
| Correctness | raise (Exception "boom") | failwith "boom" | ||||
| Performance | s.Contains "x" | s.Contains 'x' | ||||
| Performance | `xs \ | > Seq.toList \ | > List.map f` | `xs \ | > Seq.map f \ | > Seq.toList` |
| Idiom | `match b with \ | true -> 1 \ | false -> 0` | if b then 1 else 0 | ||
| Redundancy | new StringBuilder() | StringBuilder() | ||||
| Redundancy | [ ] | [ ] | ||||
| Diagnostics | failwith "Error" | failwith $"Error, calling f with x: {x}" |
A spread of what the 150-odd rules do - the full list is in Refactorings:
The analyzers ship as FSharp.Refactor.Analyzers. The package is a development dependency: it only produces hints and quick fixes - nothing from it flows into your compiled output.
NOTE: EVEN WHEN ADDING A NUGET REFERENCE, THIS ANALYSER WILL NOT COME TO OUTPUT PATH (BIN) AND WILL NOT BE PART OF YOUR PROJECT.
Easiest: install the FSharp.Refactor VS Code extension
Ionide's settings globally, so every F# project gets the hints with no per-project setup.
Or wire a single project by hand: reference the package from the project you want analyzed:
<PackageReference Include="FSharp.Refactor.Analyzers" Version="*" PrivateAssets="all" />
then point Ionide at the restored analyzers in .vscode/settings.json:
{
"FSharp.enableAnalyzers": true, "FSharp.analyzersPath": [ "~/.nuget/packages/fsharp.refactor.analyzers/ /analyzers/dotnet/fs" ] }
replacing with the version restore actually picked (the NuGet cache always keys folders by version, so this one path cannot float; check with ls ~/.nuget/packages/fsharp.refactor.analyzers/). On Windows the cache lives under %USERPROFILE%\.nuget\packages. Suggestions appear as Hint-severity diagnostics with a light-bulb one-click fix.
FsAutoComplete 0.85+ titles each fix by what it writes (Fix FR0136 → Guid.NewGuid()); an older one says only Fix FR0136. Ionide bundles its own FsAutoComplete; to run a newer one, dotnet tool install -g fsautocomplete and set FSharp.fsac.netCoreDllPath to its fsautocomplete.dll (the extension above offers to do both).
The package ships the analyzers built against TWO FSharp.Analyzers.SDK versions side by side - FSharp.Refactor.Analyzers.Ionide.dll for SDK 0.35.0 (what stock Ionide's FsAutoComplete bundles, 7.31.x and earlier) and FSharp.Refactor.Analyzers.dll for SDK 0.37.2 (the CLI, and FsAutoComplete 0.84+). The SDK loads only the assembly matching its own version and logs a skip line for the other, so every host picks the one it can use and no configuration choice is needed.
If no suggestions appear, open Output -> "F# Language Service": it names the analyzer dlls it scanned and how many analyzers loaded, and a version-pairing skip is spelt out there rather than surfacing in the editor.
Install the FSharp.Refactor Visual Studio extension (user-facing overview): squiggles and Ctrl+. quick fixes in full Visual Studio, analyzed through an FsAutoComplete sidecar. One prerequisite: dotnet tool install -g fsautocomplete.
dotnet tool install --global fsharp-analyzers
fsharp-analyzers --project src/YourProject.fsproj --analyzers-path ~/.nuget/packages/fsharp.refactor.analyzers/ /analyzers/dotnet/fs --code-root . --report analysis.sarif
fsharp-analyzers is the analyzer HOST, and it is the dotnet tool you install. This package is not a tool: it is a library of analyzer assemblies the host loads, so it is passed as a directory rather than installed. That directory sits in the NuGet cache because an analyzer package deliberately has no lib/ folder and is marked a development dependency - a PackageReference therefore puts nothing in your bin, and after a restore, the cache is where the assemblies live. --analyzers-path takes any folder holding them and searches it recursively.
The CLI only REPORTS; it never edits your files, which is what you want in CI (SARIF output works in GitHub code scanning). To apply the fixes, use our own tool below. Individual rules can be turned off per repository with a fsharprefactor.json - see Configuration below.
The fsharp-refactor dotnet tool applies the quick fixes directly to your files:
dotnet tool install --global fsharp-refactor
fsharp-refactor Your.fsproj [--dry-run] [--codes FR0002,FR0031] [--api-changes] [--jobs 4] [--max-passes 5]
(or from this repository: dotnet run --project src/FSharp.Refactor.Tool -c Release -- Your.fsproj ...)
For a project it takes the exact compiler arguments from MSBuild; for a script FCS resolves the references itself and MSBuild never runs. Either way it then runs every analyzer, applies non-overlapping fixes bottom-up, and re-analyzes until a pass applies nothing - a fix can enable further fixes. It refuses a compilation that already has errors, and fails loudly if applying ever introduces one.
Warnings as errors: the project's own settings decide, and the tool never overrides them - its verification is the build your CI runs. The in-memory typecheck takes the compiler's own arguments, so --warnaserror and turn an F# warning a fix raises into an error the pass rolls back. A C# project that references the F# one and turns an analyzer warning into an error (error CA1859, error IDE0005) fails the verification build as code, not as tooling noise, and the run says which setting to change if you want such fixes anyway ( CA1859 , or dotnet_diagnostic.CA1859.severity = suggestion). works too, but silences the analyzer for everyone.
| Flag | ||
|---|---|---|
--dry-run | Report only: lists every fix it would make, with file and position, and writes nothing. Rewriting is never implicit - drop the flag to let it edit. | |
--codes FR0002,FR0031 | Restrict the run to chosen rules; the other analyzers do not run. | |
--categories | Restrict the run to kinds of rule: correctness, performance, idiom, cosmetic. Combined with --codes it narrows further, in either order. The analyzers of the rules left out do not run at all. A filtered run can stop at a point a full run passes through: FR0157 (idiom) leaves a ` | _ ->` that FR0072 (correctness) closes in the next pass of a full run, so an idiom-only run leaves it open. See Someone else's codebase. |
--jobs | Typecheck that many files at once (default 4, clamped to 2-4 by core count). Trades CPU for wall clock; because FCS reuses each file's prefix within one incremental build, the gain peaks around 4 and reverses if pushed higher. --jobs 1 is the sequential sweep. | |
--framework | Analyse against this target framework instead of the narrowest one - see below. | |
--max-passes | Fix-then-reanalyze iterations (default 5). A pass after the first sweeps only the files the previous pass changed and those compiled after the first of them. | |
--help | The same list, from the tool itself (-h and /? also work). | |
--api-changes | Also apply the cross-file fixes described below. | |
--no-if-defs | Never emit #if/#else/#endif pairs for capability fixes on multi-targeted projects (see below). The fixes stay plain, and any the legacy frameworks reject are put back by the final build check. | |
--report | Write every finding the run surfaced to a file; the extension picks the format. .sarif (or .json) is SARIF 2.1.0 - what GitHub code scanning renders as inline PR annotations; .html is a self-contained page with per-rule grouping, highlighted source, before/after fixes and category filters; .csv is one row per finding for a spreadsheet. Pairs naturally with --dry-run for a CI lint gate. See CI setup below. A many-target run rewrites the report after every target, so a crash or a Ctrl-C an hour in still leaves what was found. Pointing the tool at a workspace of checkouts - a directory with no solution of its own whose sub-directories carry theirs, C:git say - analyses each checkout on its own (its solutions honoured, its fsharprefactor.json applied) into the one report, with paths relative to the workspace. | |
--baseline | The ratchet: findings whose fingerprints appear in this earlier --report output are neither reported nor fixed - only what is NEW surfaces. Fingerprints hash the rule code, file name and normalized surrounding source, so they survive line shifts, other edits in the file, and different checkouts. Triage once, ratchet forever. | |
--fail-on-findings | Exit 3 when any finding survives the filters - the hard CI gate. The full exit contract: 0 clean, 1 analysis or apply failure, 2 usage error, 3 findings (only with this flag). |
| --notes [on|off|only] | --notes (or --notes on) lists fix-less advisory notes inline; --notes only is the review pass described next. By default a run prints its FIXES - the product - and ends with one per-category note count (41 advisory note(s) held: …); SARIF (--report) and --format json
Nur der Anfang wird gezeigt; den Rest findest du im Repo