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 스타일 명령 실행 — VM도 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 데모

$ 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-vs-fauxnix 격차는 테스트된 모든 모델에 대해 그대로였습니다 — 최악의 경우(kimi-k2-thinking): PowerShell 작성 시 3.1배 느리고 오류 이벤트 24건인 반면 fauxnix는 오류 0건. fauxnix는 bash 툴체인을 설치하지 않고도 실제 bash의 상한선 대비 ~15% 이내에 도달합니다.

Related MCP server: wmux

왜 필요한가

LLM 에이전트는 PowerShell보다 bash에서 훨씬 뛰어납니다 — bash가 학습 데이터를 지배하므로 Windows의 모델은 종종 "맞아 보이지만 실행되지 않는" 명령을 생성합니다(잘못된 따옴표, curl이 아닌 curl, 코드페이지 불일치로 인한 글자 깨짐, 판독 불가능한 CategoryInfo 오류 덤프). 기존 솔루션은 전체 VM(WSL — 무겁고, 파일 시스템이 다르고, 별도의 환경)이거나 단순한 셸 래퍼(내부는 여전히 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입니다.

요구 사항: PowerShell 5.1+(기본 제공) 및 Node.js ≥ 18이 포함된 Windows.

빠른 시작

# 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 스타일 따옴표로 네이티브로 통과됩니다 — 문자열 재파싱도, 따옴표 버그도 없습니다.

에이전트 하네스와 함께 사용

fauxnix는 bash 도구(및 fauxnix_translate, fauxnix_session)를 노출하는 MCP stdio 서버를 제공합니다. 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 서버는 TOML 설정이 아닌 JSON 파일에 있습니다: ~/.kimi-code/mcp.json

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

모든 MCP 클라이언트 — stdio 서버: fauxnix mcp. 도구 이름은 bash입니다 (FAUXNIX_TOOL_NAME으로 재정의 가능). 도구 설명에 지원되는 하위 집합이 이미 포함되어 있으므로 시스템 프롬프트를 변경할 필요가 없습니다.

MCP 세션은 도구 호출 간에 cwd, 환경 변수, export/unset, cd -/OLDPWD를 유지합니다 — 상태 없는 exec가 아니라 로그인된 셸처럼 동작합니다.

무엇이 번역되나

개발 중에 Windows(Git Bash)의 실제 GNU coreutils와 출력을 모두 대조한 ~105개 명령:

  • 파일: 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

  • 셸/시스템: 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

여기에 셸 구문도 포함됩니다: 파이프, && / || / ;, 리다이렉션(> >> 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 호출 0회.

  • 각 명령은 "Fauxnix 계약"을 따르는 자체 완결형 PowerShell 블록을 생성하는 제너레이터에 매핑됩니다: 줄 단위 문자열 stdout, bash 스타일 stderr용 [Console]::Error.WriteLine, 종료 코드용 $script:fx_exit, stdin용 $input.

  • 실행기는 모든 스크립트를 UTF-8 강제([Console]::OutputEncoding, $OutputEncoding, chcp 65001)로 감싸고, 레거시 네이티브 도구를 위해 GBK(936) 폴백이 있는 strict-UTF-8로 출력을 디코딩하며, stderr에서 CLIXML 직렬화와 PowerShell 잡음을 제거하고, 일반적인 PowerShell 오류(zh-CN 로케일 메시지 포함)를 bash 표현으로 다시 작성합니다.

  • 스크립트는 -EncodedCommand(UTF-16LE)로 실행되며 32KB 명령줄 제한을 초과할 경우 투명하게 임시 .ps1 파일로 대체됩니다.

알려진 차이점 (솔직한 목록)

fauxnix는 에이전트가 실제로 실행하는 명령에 최적화되어 있습니다. 문서화된 차이점:

  • X=1 단독 할당은 export 의미론을 따릅니다(세션 전체에 걸친 단일 환경; bash의 셸 변수 대 내보낸 변수 구분은 존재하지 않음). 또한 같은 세그먼트의 접두사는 명령 자체의 단어 안에서 $VAR에 보입니다(Z=in [[ $Z == in ]]은 여기서 참이지만, 단어 확장이 임시 환경보다 먼저 일어나는 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>은 bash가 내장 이름만 출력하는 곳에서 /usr/bin/<name>을 출력합니다. 종료 코드와 빈 결과의 의미는 일치합니다.

  • chmod는 읽기 전용 비트만 매핑합니다. 실행 비트는 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은 에이전트 주도 HTTP의 안전 기본값으로 루프백/사설/예약 주소(localhost, 127.x, ::1, 10.x, 172.16–31.x, 192.168.x, 169.254.x)를 거부합니다.

  • 네이티브 도구 파이프라인과 인코딩: PS 5.1에는 콘솔 인코딩 설정이 하나뿐이라, 지역화된 관리 도구(ipconfig, tasklist — zh-CN에서 GBK)와 UTF-8 네이티브 개발 도구(node, curl)를 파이프라인 중간에서 둘 다 깨끗하게 디코딩할 수 없습니다. 기본값은 UTF-8 개발 도구를 우선합니다. 에이전트가 Windows 네이티브 관리 도구의 중국어 출력을 grep할 때는 FAUXNIX_NATIVE_ENCODING=ansi를 설정하세요. 파일 읽기는 항상 파일별로 감지됩니다 (UTF-8 strict → 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