A
licenseB
qualityD
maintenanceHigh-performance MCP server giving AI agents advanced filesystem and automation capabilities on Windows, with 26 tools across file I/O, search, Git, process management, and more.
26
2
MIT
fauxnix
by 20000419
fauxnix
Führen Sie Linux-artige Befehle unter Windows aus – nativ, deterministisch, ohne VM und ohne WSL.
fauxnix ist eine bash→PowerShell-Übersetzungsschicht, die für KI-Agenten entwickelt wurde. Ihr Agent schreibt weiterhin das
bash, das er bereits kennt (ls -la | grep foo, find . -name '*.ts' | wc -l, kill -9 1234), und
fauxnix übersetzt jeden Befehl deterministisch in PowerShell, führt ihn nativ aus und liefert
Ausgaben, die wie GNU/Linux aussehen: ls -l-Spalten, bash-artige Fehlermeldungen, coreutils-Exit-Codes,
UTF-8/GBK werden automatisch verarbeitet.
npm install -g fauxnix-cli # then point any MCP harness at `fauxnix mcp`
$ fauxnix "ls -la src | head -2"
-rw-r--r-- 1 me me 1204 Aug 16 09:12 ast.ts
-rw-r--r-- 1 me me 8192 Aug 16 09:12 cli.ts
$ fauxnix "cat nope.txt"
cat: nope.txt: No such file or directory # not a PowerShell stack traceGemessen: Ihr Modell ist wahrscheinlich schlechter in PowerShell, als Sie denken
Gleiches Modell (DeepSeek-V4-Pro), gleiche 5 Aufgaben, drei Ausführungsmodi auf einem Windows-Rechner –
vollständige Daten in docs/benchmark-deepseek-v4-pro.md und
`docs/benchmark-ark-models.md:
PowerShell | fauxnix | Git Bash | |
Tool-Aufrufe / unerwartete Fehler | 14 / 9 | 7 / 0 | 4 / 0 |
Zeit (T1–T4) | 163s | 66s | 57s |
Über 7 Modelle im Volcano Ark Coding Plan hinweg hielt die PowerShell-vs-fauxnix-Lücke für jedes getestete Modell – schlimmster Fall (kimi-k2-thinking): 3,1× langsamer mit 24 Fehlerereignissen beim Schreiben von PowerShell gegenüber null Fehlern durch fauxnix. fauxnix landet innerhalb von ~15 % der echten-bash-Obergrenze, ohne dass eine bash-Toolchain installiert ist.
Related MCP server: wmux
Warum
LLM-Agenten sind deutlich besser in bash als in PowerShell – bash dominiert die Trainingsdaten, daher
produzieren Modelle unter Windows oft Befehle, die „richtig aussehen, aber nicht laufen“ (falsche Quoting,
curl, das kein curl ist, Mojibake durch Codepage-Konflikte, unverständliche CategoryInfo-Fehlerausgaben). Bestehende
Lösungen sind entweder eine vollständige VM (WSL – schwer, falsches Dateisystem, separate Umgebung) oder einfache
Shell-Wrapper (immer noch PowerShell darunter).
fauxnix geht den dritten Weg: übersetzen, nicht emulieren. Eine große, wertvolle Teilmenge der Linux-Kommandozeile – Dateioperationen, Textverarbeitung, Prozessverwaltung, Archive, Netzwerk-Grundlagen – lässt sich sauber auf PowerShell + .NET abbilden. fauxnix implementiert diese Teilmenge getreu und scheitert laut und hilfreich bei dem, was es nicht übersetzen kann, sodass der Agent niemals stillschweigend falsche Ergebnisse erhält.
Installation
npm install -g fauxnix-cliOder aus dem Quellcode:
git clone https://github.com/20000419/fauxnix && cd fauxnix && npm install -g .Der npm-Paketname ist
fauxnix-cli(der Namefauxnixauf npm gehört zu einer nicht verwandten Websocket-Bibliothek von 2015); der installierte Befehl ist weiterhinfauxnix.
Erfordert: Windows mit PowerShell 5.1+ (integriert) und Node.js ≥ 18.
Schnellstart
# one-off commands
fauxnix "ls -la"
fauxnix "grep -rn TODO src | wc -l"
fauxnix "cat log.txt | grep -i error | sort | uniq -c"
# see what a command becomes (great for debugging / learning PS)
fauxnix translate "find . -name '*.log' -mtime +7 -delete"
# check your environment
fauxnix check
# run the MCP stdio server (what agent harnesses connect to)
fauxnix mcpUnbekannte Befehle (git, node, npm, python, cargo, gh, docker, ...) werden nativ durchgereicht mit argv-artigem Quoting – kein erneutes Parsen von Strings, keine Quoting-Fehler.
Verwendung mit Ihrer Agenten-Umgebung
fauxnix enthält einen MCP-stdio-Server, der ein bash-Tool bereitstellt (plus fauxnix_translate und
fauxnix_session). Richten Sie jede MCP-fähige Umgebung darauf aus:
Claude Code
claude mcp add fauxnix -- fauxnix mcpCodex (~/.codex/config.toml oder codex mcp add fauxnix -- fauxnix mcp)
[mcp_servers.fauxnix]
command = "fauxnix"
args = ["mcp"]Hinweis: Im nicht-interaktiven codex exec-Modus werden MCP-Tool-Aufrufe automatisch von der
Genehmigungsebene abgelehnt; übergeben Sie --dangerously-bypass-approvals-and-sandbox (oder führen Sie
interaktiv aus und genehmigen Sie einmal).
OpenCode (opencode.json)
{
"mcp": {
"fauxnix": { "type": "local", "command": ["fauxnix", "mcp"] }
}
}Kimi Code – anders als die anderen leben MCP-Server in einer JSON-Datei, nicht in der
TOML-Konfiguration: ~/.kimi-code/mcp.json
{
"mcpServers": {
"fauxnix": { "command": "fauxnix", "args": ["mcp"] }
}
}Jeder MCP-Client – stdio-Server: fauxnix mcp. Der Tool-Name ist bash (überschreibbar mit
FAUXNIX_TOOL_NAME). Die Tool-Beschreibung lehrt dem Modell bereits die unterstützte Teilmenge, sodass keine
Änderungen am System-Prompt erforderlich sind.
Die MCP-Sitzung behält cwd, Umgebungsvariablen, export/unset und cd -/OLDPWD über
Tool-Aufrufe hinweg bei – sie verhält sich wie eine angemeldete Shell, nicht wie ein zustandsloses exec.
Was übersetzt wird
~105 Befehle, alle während der Entwicklung gegen echte GNU-coreutils unter Windows (Git Bash) abgeglichen:
Dateien:
ls cp mv rm mkdir rmdir touch mktemp ln readlink realpath basename dirname stat file du df find chmod chown diffTextfilter:
grep egrep sed awk sort uniq cut tr– sed/awk-Skripte werden zur Übersetzungszeit geparst (nicht unterstützte Konstrukte werfen benannte Fehler, verhalten sich nie stillschweigend falsch)Text-E/A:
echo printf cat head tail wc tee nl tac md5sum sha1sum sha256sum base64 seq yes xargsShell/System:
cd pwd export unset env printenv ps kill pkill pgrep sleep which type whoami id groups date uname hostname uptime free nproc clear true false test [ [[ : pushd popd dirs sudo timeout man history less more source . eval exit alias setNetzwerk:
curl wget ping netstat ss ip ifconfig nslookup dig hostArchive:
tar gzip gunzip zcat zip unzip
Plus Shell-Syntax: Pipes, && / || / ;, Umleitungen (> >> 2> 2>&1 < &>, /dev/null),
Quoting, $VAR $(...)-Befehlsersetzung, VAR=x cmd-Präfixe, ~-Erweiterung und
POSIX-artige Pfadnormalisierung (/tmp, /d/foo → D:\foo).
Exit-Codes folgen bash-Konventionen: 0 ok, 1 Fehler, 2 Verwendung/schwerwiegend, 127 Befehl nicht gefunden, 124 Zeitüberschreitung.
So funktioniert es
bash command ──parser──▶ AST ──translator──▶ PowerShell script ──executor──▶ powershell.exe
│
agent ◀── GNU-style output, bash-style errors ◀── decoder (UTF-8 → GBK fallback) ◀┘Deterministische Übersetzung, null LLM-Aufrufe zur Laufzeit.
Jeder Befehl wird auf einen Generator abgebildet, der einen eigenständigen PowerShell-Block ausgibt, der den „Fauxnix-Vertrag“ einhält: eine Zeile pro String auf stdout,
[Console]::Error.WriteLinefür bash-artiges stderr,$script:fx_exitfür Exit-Codes,$inputfür stdin.Der Executor umhüllt jedes Skript mit UTF-8-Erzwingung (
[Console]::OutputEncoding,$OutputEncoding,chcp 65001), dekodiert Ausgaben als striktes UTF-8 mit einem GBK(936)-Fallback für ältere native Tools, entfernt CLIXML-Serialisierung und PowerShell-Rauschen aus stderr und schreibt häufige PowerShell-Fehler (einschließlich zh-CN-Locale-Meldungen) in bash-Formulierung um.Skripte laufen über
-EncodedCommand(UTF-16LE) und fallen transparent auf eine temporäre.ps1-Datei zurück, wenn das 32-KB-Kommandozeilenlimit überschritten würde.
Bekannte Abweichungen (ehrliche Liste)
fauxnix optimiert für die Befehle, die Agenten tatsächlich ausführen. Dokumentierte Abweichungen:
X=1-Einzelzuweisungen folgen derexport-Semantik (eine sitzungsweite Umgebung; bash's Unterscheidung zwischen Shell-Variable und exportierter Variable existiert nicht), und ein Präfix im selben Segment ist für$VARinnerhalb der eigenen Wörter des Befehls sichtbar (Z=in [[ $Z == in ]]ist hier wahr, in bash falsch, wo die Worterweiterung vor der temporären Umgebung erfolgt).yesist auf 65.536 Zeilen begrenzt – PS-5.1-Pipelines können Upstream-Produzenten nicht signalisieren, anzuhalten, daher würde ein unbegrenztesyes | headhängen bleiben.tail -f,eval,alias, Heredocs,while/until/case, wortweise$((...))-Arithmetik-Erweiterung und Hintergrund-&werden mit umsetzbaren Fehlermeldungen abgelehnt, anstatt sich falsch zu verhalten. (if/then/else/fi,for x in ..., Backtick-Ersetzung,command -v, Pipeline-read, und dotenv-artigessourcewerden unterstützt.)command -v <builtin>gibt/usr/bin/<name>aus, während bash den bloßen Builtin-Namen ausgibt; Exit-Codes und Semantik bei leerem Ergebnis stimmen überein.chmodbildet nur das Schreibschutz-Bit ab; Ausführungsbits sind unter Windows wirkungslos.chownist ein stilles No-op (wie in Git Bash).ps aux-Spalten sind Näherungen (keine CPU%-Berechnung pro Prozess, USER zeigt?).gzip -c/Pipeline-Stdin ist textgetreu, nicht bytegetreu; Dateimodusgzip fist byteexakt.Eine Pipeline, die genau eine Zeile erzeugt und in
wc -lgeleitet wird, zählt diese Zeile (bash würde 0 zählen, wenn der Produzent das abschließende Newline weglässt).printf 'x' | md5sumbleibt byteexakt.sed/awkunterstützen die gängige Teilmenge; Hold-Space, Labels, Arrays, Schleifen werfen benannte „nicht unterstützt“-Fehler zur Übersetzungszeit.curl/wgetlehnen Loopback-/private/reservierte Adressen ab (localhost, 127.x, ::1, 10.x, 172.16–31.x, 192.168.x, 169.254.x) als Sicherheitsstandard für agentengesteuertes HTTP.Native-Tool-Pipelines vs. Kodierung: PS 5.1 hat einen einzigen Konsolen-Kodierungsregler, daher können Pipelines mit lokalisierten Admin-Tools (ipconfig, tasklist – GBK auf zh-CN) und UTF-8-nativen Entwicklungs- tools (node, curl) nicht beide mitten in der Pipeline sauber dekodieren. Standard bevorzugt UTF-8-Entwicklungs- tools; setzen Sie
FAUXNIX_NATIVE_ENCODING=ansi, wenn Ihre Agenten chinesische Ausgaben von nativen Windows-Admin-Tools durchsuchen. Dateilesungen werden immer pro Datei erkannt (UTF-8 strikt → GBK-Fallback), sodass grep/sed/awk über GBK-Dateien in beiden Modi funktioniert – anders als Git Bash, das nur die Kodierung abgleicht, die sein Locale annimmt.
Entwicklung
npm install
npm test # unit + real-PowerShell integration suite (Windows only, auto-skipped elsewhere)
npm run build
npx tsx scratch/run.mjs "any bash command" # quick live checkArchitekturübersicht: src/parser.ts (bash-Teilmenge → AST) · src/translator.ts (AST → PowerShell +
Executor-Wrapper) · src/executor.ts (spawn, Umleitungen, Sitzungspersistenz) ·
src/commands/*.ts (Befehlsgeneratoren) · src/mcp.ts (MCP-Server) · src/cli.ts.
Lizenz
MIT © 20000419
Available Tools
4 toolsbashADestructive
Execute a Linux/bash-style command on this Windows machine.
Commands are deterministically translated to PowerShell and executed natively — no WSL or VM. Output is formatted to look like GNU/Linux tooling (ls -l, ps aux, df -h ...), errors look like bash errors, and text encoding (UTF-8/GBK) is handled automatically.
Supported: pipes (|), && / || / ;, redirections (> >> 2> 2>&1 < /dev/null), variables ($VAR $HOME $1 $# "$@" ~), set -- / shift, array assignment A=(x y z), ${name[n]} ${#name[@]} ${name//pat/str} ${name:off:len}, command substitution $(...), and 109+ coreutils-style commands (., :, [, [[, alias, awk, base64, basename, cat, cd, chmod, chown, clear, command, cp, curl, cut, date...). Unknown commands (git, node, npm, python, cargo...) are passed through and executed natively with argv-style quoting. Not supported: heredocs, env -i/--ignore-environment, background jobs. if/then/elif/else/fi, for-in loops, while/until, case ... esac, and word-level $((...)) arithmetic expansion are supported. CWD, environment variables, export/unset, cd, and positional parameters (set -- / $1 / "$@") persist across calls within this session — a resident PowerShell 5.1 host is started when the MCP session begins (and after reset), so the first bash tool call is already warm. Efficiency: when two or more commands or verification steps are already known, prefer bash_batch once instead of making several bash calls. Keep separate calls only when the next command requires model interpretation of the previous output. For byte-exact work, measure with wc -c or stat -c %s instead of inferring CRLF byte counts from displayed text. MCP capture is bounded to 256 KiB stdout and 64 KiB stderr across the complete command list; larger output is marked truncated. Redirect larger artifacts to files. These transport-safe budgets include room for JSON escaping and duplicate text/structured fields. Exit codes follow bash conventions (0 ok, 1 fail, 2 usage/serious, 127 command not found, 124 timeout, 130 cancelled). The tool also returns structuredContent (schemaVersion 1) with stdout/stderr/exitCode/timedOut/cancelled/truncated/sessionId.
Platform requirement: the execution backend is native Windows PowerShell 5.1+. On hosts without PowerShell on PATH (e.g. Linux containers/sandboxes), the bash tool returns exit code 127 with an actionable error instead of running the command.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The bash-style command line to run | |
| timeout_ms | No | Timeout in milliseconds (default 120000) |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/openWorld, but the description adds substantial non-obvious behavior: output is GNU-style formatted, encoding is auto-handled, session state (CWD, env, positional params) persists via a resident PowerShell host, output is truncated past 256 KiB stdout / 64 KiB stderr, and exit codes follow bash conventions with specific values. This is well beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose before diving into capability lists, and every paragraph addresses a decision an agent must make. It is long, and one sentence about JSON escaping/duplicate fields is meta-commentary that does not help invocation, but overall the density is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies the return shape via structuredContent (stdout/stderr/exitCode/timedOut/cancelled/truncated/sessionId), explains truncation budgets and exit-code semantics, and covers the platform prerequisite. An agent has everything needed to call and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and only two parameters exist, so the schema documents both fields. The description nonetheless adds real meaning to the command parameter by enumerating supported constructs (pipes, redirections, variables, arrays, command substitution, 109+ coreutils) and passthrough behavior for unknown commands like git/node.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Execute) and resource (a Linux/bash-style command) and immediately scopes the target platform (this Windows machine). It even names the sibling bash_batch as the preferred tool for multi-command flows, making it distinguishable without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes when to use bash_batch once instead of several bash calls, and when to keep calls separate (when the next command needs model interpretation of prior output). It also provides an actionable fallback rule for environments without PowerShell and a recommendation to redirect large artifacts to files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bash_batchADestructive
Compile and execute a preplanned multi-step bash workflow in one MCP round trip.
Use this instead of repeated bash calls when the complete sequence is already known. Steps run serially and atomically in the same persistent session: later steps see cwd, environment, and files from earlier steps, while run/reset requests cannot interleave. Every command is parsed and translated before step 1 runs, and the result reports each step separately.
By default the batch stops after the first nonzero exit. Set stop_on_error=false only when later steps should still run. timeout_ms and both output limits apply to the whole batch, not once per step. Output defaults to 256 KiB stdout and 64 KiB stderr; redirect larger artifacts to files. Preflight performs no operand-file reads: use sed -e with inline script text instead of sed -f. If a later command depends on model interpretation of an earlier result, use separate bash calls instead. For byte counts, include wc -c or stat -c %s as a verification step rather than calculating CRLF bytes mentally.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Ordered workflow steps; all are compiled before execution begins | |
| timeout_ms | No | Total timeout for the complete batch (default 120000) | |
| stop_on_error | No | Stop after the first nonzero exit (default true) | |
| stderr_limit_bytes | No | Total stderr budget shared by every step (default 65536) | |
| stdout_limit_bytes | No | Total stdout budget shared by every step (default 262144) |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavioral traits beyond the annotations: steps run serially and atomically in one persistent session, commands are pre-parsed before execution, output limits apply per-batch not per-step, preflight does no operand-file reads, and redirects are recommended for large artifacts. This complements the destructive/open-world hints with actionable detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a complex batch tool. It front-loads the core purpose and usage, then covers behavioral constraints, defaults, and caveats in a logical order. Every sentence conveys useful guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by explaining step result reporting, failure behavior, session persistence, output limits, and preflight limitations. An agent has enough context to correctly select and invoke the tool, including how to handle large outputs and byte-count verification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds meaningful semantics beyond the schema: timeout_ms and output limits apply to the whole batch rather than per step, and stop_on_error=false is recommended only when later steps should still run. This exceeds the baseline for fully-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compile and execute a preplanned multi-step bash workflow in one MCP round trip') and explicitly contrasts it with repeated bash calls. It clearly distinguishes this tool from the single-command sibling bash by focusing on preplanned multi-step workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use instead of repeated bash calls when the complete sequence is already known. It also provides exclusions: use separate bash calls when later steps depend on model interpretation of earlier results, and explains when stop_on_error=false is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fauxnix_sessionAIdempotent
Inspect or reset the persistent fauxnix shell session (current directory, environment, positional count, session id). Actions: "status" (default) or "reset".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | "status" shows the session state (cwd, tracked env keys, positional count); "reset" clears it back to a fresh shell | status |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark idempotentHint=true and destructiveHint=false; the description adds that reset 'clears it back to a fresh shell' and enumerates what status exposes. This contextualizes the mutation behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence states the operation, resource, and fields, then a compact action list. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional enum parameter, no output schema, and detailed action semantics in the schema, the description covers the essentials including reset side effects. It could specify the shape of a status response, but that is a minor gap for such a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the action property already explains both enum values. The tool description adds only 'session id' to the status contents, so it slightly extends but does not need to compensate for the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (inspect/reset), a precise resource (persistent fauxnix shell session), and the exact state fields. This separates it clearly from sibling tools like bash and fauxnix_translate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action enum and sentence imply when to use it (inspect or reset session state), but there is no explicit guidance about when not to use it or which sibling would be preferred. Usage context is clear enough by implication, but no exclusion or alternative is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fauxnix_translateARead-onlyIdempotent
Translate a bash-style command into the equivalent PowerShell script WITHOUT executing it. Useful for learning/debugging what fauxnix does under the hood.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The bash-style command line to translate (never executed) |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds behavioral context by emphasizing 'WITHOUT executing it' and that the command is 'never executed', reinforcing safety beyond the annotations. This matches the bar for adding value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and immediate caveat (no execution) in the first sentence, then stating the use case. Every sentence earns its place without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and rich annotations (readOnly, idempotent, non-destructive), the description is complete enough. It explains the translation function, non-execution guarantee, and appropriate use case. The absence of return value detail is acceptable since there is no output schema to contradict, and the use case is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (1 parameter fully described in schema), so the baseline is 3. The description adds minimal parameter information beyond the schema (just reiterates 'bash-style command line'), but it does clarify that the command is never executed, which complements the schema description. No enum parameters exist to add further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool translates a bash-style command into PowerShell without executing it, specifying the verb 'Translate' and the resource 'bash-style command'. It distinguishes itself from siblings like 'bash' or 'fauxnix_session' by highlighting its non-execution and translation-only purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is for learning or debugging what fauxnix does under the hood, providing clear context for when to use it. However, it does not specify when not to use it or mention alternatives, though the sibling 'bash' implies execution which contrasts with this tool's non-execution nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.13.0- Added
bash_batch - Changed
fauxnix_session1 field changed- changed
Input schema / properties / action / descriptionPrevious value: -"\"status\" shows the session state (cwd, tracked env keys); \"reset\" clears it back to a fresh shell"New value: +"\"status\" shows the session state (cwd, tracked env keys, positional count); \"reset\" clears it back to a fresh shell"
3 tool updates
- First observed
bash - First observed
fauxnix_session - First observed
fauxnix_translate
TDQS
A4.2/5.0
Scored across 4 tools
Disambiguation4/5
bash and bash_batch overlap in purpose (both execute commands), but the descriptions give clear guidance on when to use each (batch for preplanned sequences, separate calls when model interpretation is needed). fauxnix_session and fauxnix_translate are clearly distinct. Only minor risk of misselection between the two execution tools.
Naming Consistency3/5
Two naming families coexist: bare 'bash'/'bash_batch' (shared prefix, but no verb_noun form) and 'fauxnix_session'/'fauxnix_translate' (server-prefixed). The pattern is readable and not chaotic, but conventions are mixed rather than uniform.
Tool Count5/5
Four tools is well-scoped for a shell-emulation server: execution, batched execution, session inspection, and translation each earn their place with no redundancy.
Completeness4/5
The surface covers execution, batch workflows, session status/reset, and translation introspection, which is solid lifecycle coverage for a shell proxy. Minor gap: no direct way to kill or interrupt a running process beyond reset, but core workflows are covered.
Maintenance
ActivityActive
ResponsivenessResponsive
Related MCP Connectors
LLM Orchestration Agent (Mcp)
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
1Linux microVM sandboxes for AI agents: run commands, files, processes, pause and wake.
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceA native Windows terminal multiplexer with MCP bridge for AI agents, enabling browser automation, multi-agent coordination, and terminal control.424MIT
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants to execute PowerShell commands, manage files, inspect projects, run Git operations, and monitor system information on Windows through a local MCP server.-
- AlicenseNot gradedqualityBmaintenanceProvides a local Windows control plane for PowerShell and AI CLIs, exposing MCP tools for safe terminal sessions, bounded provider calls, routing, committees, and run receipts.5 npmMIT