Skip to main content
Glama
20000419

fauxnix

by 20000419
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

bash

Destructive

Run Linux/bash-style commands on Windows without WSL or a VM. Translates bash syntax to native PowerShell, supports pipes, redirections, variables, and 100+ coreutils commands, returning bash-style output and exit codes.

Instructions

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. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesThe bash-style command line to run
timeout_msNoTimeout in milliseconds (default 120000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only say readOnly=false, destructive=true, idempotent=false. The description goes far beyond with high-value behavioral disclosure: exact exit-code mapping (0/1/2/127/124/130), persistence of CWD/environment/positional params across calls via a resident PowerShell 5.1 host, platform fallback behavior (127 on non-PowerShell hosts), translation fidelity ('deterministically translated'), and return of structuredContent fields. No contradiction with annotations; the destructiveHint is consistent with running arbitrary shell commands.

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?

The description is long (roughly 400 words) but nearly every sentence carries load-bearing information: purpose first, then translation mechanism, supported syntax, unsupported cases, passthrough, persistence, exit codes, and platform requirement. The length is justified by the tool's high complexity. It is well-structured and front-loaded with the core purpose; only the 109+ coreutils-name enumeration is slightly bulky, but even it is useful for the agent.

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 having no output schema, the description explicitly documents return semantics (GNU-formatted output, bash-style errors, structuredContent with stdout/stderr/exitCode/timedOut/cancelled/truncated/sessionId) and exit-code conventions, plus failure-mode behavior on hosts without PowerShell. Given the tool's complexity (2 required-ish params, persistent side effects, and universal command input), the description is sufficient for an agent to call it correctly in nearly all contexts.

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 baseline is 3 even without additional info. The description nonetheless adds substantial meaning beyond the schema for both parameters: it documents what command syntax is supported (pipes, redirections, arrays, substitution), what is not (heredocs, background jobs), the timeout-related exit code 124, the timeout bounds/default (120000ms), and the platform conditions under which commands fail. Only timeout_ms could have been elaborated further, but the description clearly covers the important semantics.

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 opening sentence states a specific verb and resource: 'Execute a Linux/bash-style command on this Windows machine.' It further distinguishes the mechanism (deterministically translated to PowerShell, no WSL/VM) and the advertised behavior (GNU-like output/errors, automatic encoding), immediately differentiating it from siblings like bash_batch and fauxnix_translate. The passthrough clause for unknown commands (git, node, python...) also clarifies scope — it is a general command runner, not only a fixed command set.

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?

Explicit guidance routes to the main alternative: 'prefer bash_batch once instead of making several bash calls' and 'keep separate calls only when the next command requires model interpretation of the previous output.' The unsupported-features list (heredocs, background jobs) also functions as a when-not. However, the description does not address when to use the sibling tools fauxnix_session or fauxnix_translate instead, leaving part of the alternative universe unguided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools