Skip to main content
Glama
deenesjakoruzh
20000419

fauxnix

by 20000419
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

fauxnix

CI npm version npm downloads license 20000419/fauxnix MCP server

在 Windows 上以原生、确定性的方式运行 Linux 风格命令——无需虚拟机，无需 WSL。

fauxnix 是专为 AI 代理打造的 bash→PowerShell 翻译层。你的代理可以继续编写它已经熟悉的 bash 命令（ls -la | grep foo、find . -name '*.ts' | wc -l、kill -9 1234），fauxnix 会确定性地将每条命令翻译成 PowerShell，原生执行，并返回看起来像 GNU/Linux 的输出：ls -l 列、bash 风格错误消息、coreutils 退出码，UTF-8/GBK 自动处理。

npm install -g fauxnix-cli    # then point any MCP harness at `fauxnix mcp`

fauxnix demo

$ 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 trace

实测：你的模型在 PowerShell 上的表现可能比你想的更差

同一模型（DeepSeek-V4-Pro）、同样的 5 个任务、同一台 Windows 机器上的三种执行模式——完整数据见 docs/benchmark-deepseek-v4-pro.md 和 `docs/benchmark-ark-models.md：

PowerShell

fauxnix

Git Bash

工具调用 / 意外错误

14 / 9

7 / 0

4 / 0

时间（T1–T4）

163s

66s

57s

在 Volcano Ark Coding Plan 的 7 个模型中，PowerShell 与 fauxnix 之间的差距在每个测试模型上都成立——最坏情况（kimi-k2-thinking）：手写 PowerShell 比 fauxnix 慢 3.1 倍，并产生 24 个错误事件，而通过 fauxnix 零错误。在未安装任何 bash 工具链的情况下，fauxnix 也能落在真实 bash 上限的 ~15% 以内。

Related MCP server: wmux

为什么

LLM 代理在 bash 上的表现远优于 PowerShell——bash 在训练数据中占主导，因此 Windows 上的模型常常生成“看起来对、跑不起来”的命令（错误的引号、不是 curl 的 curl、代码页不匹配导致的乱码、令人费解的 CategoryInfo 错误转储）。现有解决方案要么是完整的虚拟机（WSL——笨重、文件系统不对、环境隔离），要么是单纯的 shell 包装器（底层仍是 PowerShell）。

fauxnix 走的是第三条路：翻译，而非模拟。Linux 命令行中一个庞大且高价值的子集——文件操作、文本处理、进程管理、归档、基础网络——可以干净地映射到 PowerShell + .NET。fauxnix 忠实实现了这一子集，并在无法翻译时响亮且有益地失败，因此代理永远不会得到悄悄出错的结果。

安装

npm install -g fauxnix-cli

或者从源码构建：

git clone https://github.com/20000419/fauxnix && cd fauxnix && npm install -g .

npm 包名是 fauxnix-cli（npm 上的 fauxnix 名称属于一个无关的 2015 年 websocket 库）；安装后的命令仍然是 fauxnix。

要求：Windows（自带 PowerShell 5.1+）和 Node.js ≥ 18。

快速开始

# 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 mcp

未知命令（git、node、npm、python、cargo、gh、docker……）会以 argv 风格引用原生透传——不重新解析字符串，也没有引号 bug。

配合你的代理框架使用

fauxnix 附带一个 MCP stdio 服务器，提供 bash 工具（另有 fauxnix_translate 和 fauxnix_session）。任何支持 MCP 的框架都可以接入：

Claude Code

claude mcp add fauxnix -- fauxnix mcp

Codex（~/.codex/config.toml 或 codex mcp add fauxnix -- fauxnix mcp）

[mcp_servers.fauxnix]
command = "fauxnix"
args = ["mcp"]

注意：在非交互式 codex exec 模式下，MCP 工具调用会被审批层自动拒绝；请传入 --dangerously-bypass-approvals-and-sandbox（或以交互方式运行并批准一次）。

OpenCode（opencode.json）

{
  "mcp": {
    "fauxnix": { "type": "local", "command": ["fauxnix", "mcp"] }
  }
}

Kimi Code——与其他工具不同，MCP 服务器位于 JSON 文件而不是 TOML 配置中：~/.kimi-code/mcp.json

{
  "mcpServers": {
    "fauxnix": { "command": "fauxnix", "args": ["mcp"] }
  }
}

任意 MCP 客户端——stdio 服务器：fauxnix mcp。工具名称是 bash（可通过 FAUXNIX_TOOL_NAME 覆盖）。工具描述已经教会了模型所支持的子集，因此无需改动系统提示词。

MCP 会话会在工具调用之间持久保留 cwd、环境变量、export/unset 以及 cd -/OLDPWD——它的行为像一个已登录的 shell，而不是无状态的 exec。

支持的命令

~105 条命令，开发时所有输出均在 Windows（Git Bash）上与真实 GNU coreutils 逐一对齐：

  • 文件：ls cp mv rm mkdir rmdir touch mktemp ln readlink realpath basename dirname stat file du df find chmod chown diff

  • 文本过滤：grep egrep sed awk sort uniq cut tr——sed/awk 脚本在翻译时解析（不支持的构造会抛出命名错误，绝不会悄悄出错）

  • 文本 I/O：echo printf cat head tail wc tee nl tac md5sum sha1sum sha256sum base64 seq yes xargs

  • shell/系统：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 set

  • 网络：curl wget ping netstat ss ip ifconfig nslookup dig host

  • 归档：tar gzip gunzip zcat zip unzip

此外还支持 shell 语法：管道、&& / || / ;、重定向（> >> 2> 2>&1 < &>、/dev/null）、引号、$VAR $(...) 命令替换、VAR=x cmd 前缀、~ 展开，以及 POSIX 风格路径归一化（/tmp、/d/foo → D:\foo）。

退出码遵循 bash 约定：0 成功、1 失败、2 用法错误/严重错误、127 命令未找到、124 超时。

工作原理

bash command ──parser──▶ AST ──translator──▶ PowerShell script ──executor──▶ powershell.exe
                                                                              │
agent ◀── GNU-style output, bash-style errors ◀── decoder (UTF-8 → GBK fallback) ◀┘

  • 确定性翻译，运行时零 LLM 调用。

  • 每条命令映射到一个生成器，生成自包含的 PowerShell 块，遵守“Fauxnix 契约”：stdout 逐行字符串，bash 风格 stderr 使用 [Console]::Error.WriteLine，退出码使用 $script:fx_exit，stdin 使用 $input。

  • 执行器会用 UTF-8 强制包裹每个脚本（[Console]::OutputEncoding、$OutputEncoding、chcp 65001），输出按严格 UTF-8 解码，并为旧式原生工具提供 GBK(936) 回退；从 stderr 中剥离 CLIXML 序列化和 PowerShell 噪音，并把常见的 PowerShell 错误（包括 zh-CN 区域设置消息）改写成 bash 措辞。

  • 脚本通过 -EncodedCommand（UTF-16LE）运行，并在可能超过 32 KB 命令行限制时透明地回退到临时 .ps1 文件。

已知差异（诚实清单）

fauxnix 针对代理真正会运行的命令做了优化。以下是已记录的差异：

  • X=1 独立赋值遵循 export 语义（整个会话共用一个环境；bash 中 shell 变量与导出变量的区别在这里不存在），且同一命令前缀对命令自身单词内的 $VAR 可见（Z=in [[ $Z == in ]] 在这里为真，在 bash 中为假，因为 bash 的单词展开先于临时环境）。

  • yes 最多输出 65,536 行——PS 5.1 管道无法通知上游生产者停止，因此无上限的 yes | head 会挂起。

  • tail -f、eval、alias、heredoc、while/until/case、词级 $((...)) 算术展开和后台 & 会被拒绝，并给出可操作的错误消息，而不是错误行为。（if/then/else/fi、for x in ...、反引号替换、command -v、管道 read 和 dotenv 风格的 source 受支持。）

  • command -v <builtin> 会输出 /usr/bin/<name>，而 bash 输出的是裸的内置命令名；退出码和空结果语义一致。

  • chmod 只映射只读位；exec 位在 Windows 上是空操作。chown 是静默空操作（与 Git Bash 一样）。

  • ps aux 的列是近似值（没有按进程的 CPU% 统计，USER 显示为 ?）。

  • gzip -c/管道 stdin 是文本保真，而非字节保真；文件模式 gzip f 是字节精确的。

  • 一个恰好产生一行的管道，接到 wc -l 时会计入这一行（如果生产者省略了末尾换行符，bash 会计为 0）。printf 'x' | md5sum 仍保持字节精确。

  • sed/awk 支持常见子集；hold-space、标签、数组、循环会在翻译时抛出命名“不支持”错误。

  • curl/wget 默认拒绝回环/私有/保留地址（localhost、127.x、::1、10.x、172.16–31.x、192.168.x、169.254.x），作为代理驱动 HTTP 的安全默认。

  • 原生工具管道与编码：PS 5.1 只有一个控制台编码旋钮，因此将本地化管理工具（ipconfig、tasklist——zh-CN 下为 GBK）和 UTF-8 原生的开发工具（node、curl）接入同一管道时，无法在管道中途同时干净地解码。默认优先 UTF-8 开发工具；当你的代理需要 grep 原生 Windows 管理工具的中文输出时，设置 FAUXNIX_NATIVE_ENCODING=ansi。文件读取始终按文件嗅探（严格 UTF-8 → GBK 回退），因此对 GBK 文件 执行 grep/sed/awk 在任一模式下都能工作——这与 Git Bash 不同，后者只匹配其区域设置所假定的编码。

开发

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 check

架构地图：src/parser.ts（bash 子集 → AST）· src/translator.ts（AST → PowerShell + 执行器包装）· src/executor.ts（spawn、重定向、会话持久化）· src/commands/*.ts（每条命令的生成器）· src/mcp.ts（MCP 服务器）· src/cli.ts。

许可证

MIT © 20000419

Available Tools

4 tools
bashA
Destructive

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
NameRequiredDescriptionDefault
commandYesThe bash-style command line to run
timeout_msNoTimeout 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_batchA
Destructive

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
NameRequiredDescriptionDefault
stepsYesOrdered workflow steps; all are compiled before execution begins
timeout_msNoTotal timeout for the complete batch (default 120000)
stop_on_errorNoStop after the first nonzero exit (default true)
stderr_limit_bytesNoTotal stderr budget shared by every step (default 65536)
stdout_limit_bytesNoTotal 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_sessionA
Idempotent

Inspect or reset the persistent fauxnix shell session (current directory, environment, positional count, session id). Actions: "status" (default) or "reset".

ParametersJSON Schema
NameRequiredDescriptionDefault
actionNo"status" shows the session state (cwd, tracked env keys, positional count); "reset" clears it back to a fresh shellstatus

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_translateA
Read-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
NameRequiredDescriptionDefault
commandYesThe 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.

  1. 2 tool updatesv0.13.0
    • Addedbash_batch
    • Changedfauxnix_session1 field changed
      • changedInput schema / properties / action / description
        Previous 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"
  2. 3 tool updates
    • First observedbash
    • First observedfauxnix_session
    • First observedfauxnix_translate
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

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

Resources

Related MCP Connectors

Related MCP Servers

  • COP Plug

    beepoo304
    F
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to execute PowerShell commands, manage files, inspect projects, run Git operations, and monitor system information on Windows through a local MCP server.
    -

  • relaybridge

    maximyz3d
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides 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 npm
    MIT