Skip to main content
Glama

fauxnix

CI npm version npm downloads license 20000419/fauxnix MCP server

Run Linux-style commands on Windows — natively, deterministically, with no VM and no WSL.

fauxnix is a bash→PowerShell translation layer built for AI agents. Your agent keeps writing the bash it already knows (ls -la | grep foo, find . -name '*.ts' | wc -l, kill -9 1234), and fauxnix deterministically translates each command into PowerShell, executes it natively, and hands back output that looks like GNU/Linux: ls -l columns, bash-style error messages, coreutils exit codes, UTF-8/GBK handled automatically.

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

Measured: your model is probably worse at PowerShell than you think

Same model (DeepSeek-V4-Pro), same 5 tasks, three execution modes on one Windows machine — full data in docs/benchmark-deepseek-v4-pro.md and [`docs/benchmark-ark-models.md](docs/benchmark-ark-models.md):

PowerShell

fauxnix

Git Bash

tool calls / unexpected errors

14 / 9

7 / 0

4 / 0

time (T1–T4)

163s

66s

57s

Across 7 models on the Volcano Ark Coding Plan, the PowerShell-vs-fauxnix gap held for every model tested — worst case (kimi-k2-thinking): 3.1× slower with 24 error events writing PowerShell vs zero errors through fauxnix. fauxnix lands within ~15% of the real-bash ceiling with no bash toolchain installed.

Related MCP server: wmux

Why

LLM agents are dramatically better at bash than at PowerShell — bash dominates training data, so models on Windows often produce "looks right, doesn't run" commands (wrong quoting, curl that isn't curl, mojibake from codepage mismatches, inscrutable CategoryInfo error dumps). Existing solutions are either a full VM (WSL — heavy, wrong filesystem, separate environment) or plain shell wrappers (still PowerShell underneath).

fauxnix takes the third road: translate, don't emulate. A large, high-value subset of the Linux command line — file ops, text processing, process management, archives, networking basics — maps cleanly onto PowerShell + .NET. fauxnix implements that subset faithfully and fails loudly and helpfully on what it can't translate, so the agent never gets silently-wrong results.

Labs now train computer-use agents on fleets of real desktops. Reporting in 2026 (The Information, widely repeated) has OpenAI buying tens of thousands of Mac mini / Mac Studio boxes — no screen, no keyboard — to reinforcement-learn agents that click, edit, test, and run bash workflows, and Anthropic renting Mac minis through AWS for the same class of work. That scoring environment is macOS. Windows users should not have to install a guest Unix to keep up: the agent keeps writing bash; fauxnix makes the Windows box answer like the box the agent was trained on. See docs/rfc-computer-use-windows.md.

Install

npm install -g fauxnix-cli

Or from source:

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

npm package name is fauxnix-cli (the fauxnix name on npm belongs to an unrelated 2015 websocket library); the installed command is still fauxnix.

Requires: Windows with PowerShell 5.1+ (built-in) and Node.js ≥ 18.

PowerShell 7 is an opt-in, CI-tested tier:

$env:FAUXNIX_PS = 'pwsh'
fauxnix check                 # edition: Core

Set the variable before starting fauxnix or its MCP harness; restart the harness after changing it. Windows PowerShell 5.1 remains the default. Invalid values and a missing selected executable fail loudly rather than falling back. The default is pinned below SystemRoot; pwsh.exe is resolved once from absolute PATH directories, excluding the current working directory. See PowerShell 7 support.

Quick start

# 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
fauxnix doctor                   # check + encoding, harness config, MCP

# write user-level MCP config (idempotent; also --codex/--opencode/--kimi/--qwen)
fauxnix install --claude

# run the MCP stdio server (what agent harnesses connect to)
fauxnix mcp

translate only renders a script and does not read command operands. Because sed -f needs a script file, translate-only mode asks you to use -e with inline script text; normal command execution continues to support sed -f.

Unknown commands (git, node, npm, python, cargo, gh, docker, ...) are passed through natively with argv-style quoting. Windows .cmd/.bat shims necessarily pass through cmd.exe; fauxnix preserves its supported punctuation and fails loudly for %, embedded double quotes, NUL, and line breaks rather than passing a different argument.

Use with your agent harness

fauxnix ships an MCP stdio server exposing a bash tool (plus fauxnix_translate and fauxnix_session). Point any MCP-capable harness at it with fauxnix install --claude (or --codex / --opencode / --kimi / --qwen). Idempotent; prints what changed. Manual configs below.

  • Quickstarts — copy-paste config + a 10-command smoke: docs/examples/

Claude Code

claude mcp add fauxnix -- fauxnix mcp

Codex (~/.codex/config.toml or codex mcp add fauxnix -- fauxnix mcp)

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

Note: in non-interactive codex exec mode, MCP tool calls are auto-denied by the approval layer; pass --dangerously-bypass-approvals-and-sandbox (or run interactively and approve once).

OpenCode (opencode.json)

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

Kimi Code — unlike the others, MCP servers live in a JSON file, not the TOML config: ~/.kimi-code/mcp.json

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

Qwen Code (~/.qwen/settings.json)

fauxnix install --qwen

The installer preserves the rest of settings.json and writes an absolute Node + package-entry launcher so Qwen startup does not depend on its working directory or PATH order. See the Qwen example for the generated JSON shape.

Any MCP client — stdio server: fauxnix mcp. The tool name is bash (override with FAUXNIX_TOOL_NAME). Tool description already teaches the model the supported subset, so no system-prompt changes are required.

The MCP session persists cwd, environment variables, export/unset, cd -/OLDPWD, and positional parameters (set -- / $1 / "$@") across tool calls — it behaves like a logged-in shell, not a stateless exec. $0 is the MCP tool name (bash / FAUXNIX_TOOL_NAME), not a Windows path.

What's translated

~105 commands, all output-matched against real GNU coreutils on Windows (Git Bash) during development:

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

  • text filters: grep egrep sed awk sort uniq cut tr — sed/awk scripts are parsed while preparing an executable plan (unsupported constructs throw named errors, never silently misbehave); inspect-only translate keeps sed -f file reads out of that path

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

The curated agent-daily 60 carry a CommandSpec: unknown options fail with a GNU-style usage error instead of being ignored. The generated docs/command-specs.md is the exact list, coverage count, option table, and exclusion rationale; fauxnix list --json exposes the same per-command metadata. find stays unspec'd so predicates like -name still compile; sed/awk/egrep keep their command-specific parsers; tar remains native to tar.exe so supported bsdtar options reach the executable. Implemented GNU holes include cp -n / mv -n / touch -c / tee --append / grep -m / head --lines / du --max-depth / env -u / ps -f / command -V / date --date=@SECONDS.

  • shell/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 set shift

  • network: curl wget ping netstat ss ip ifconfig nslookup dig host

  • archives: tar gzip gunzip zcat zip unzip

Plus shell syntax: pipes, && / || / ;, redirections (> >> 2> 2>&1 < &>, /dev/null), quoting, $VAR $1 $# "$@" set -- shift, ${name:-word} ${name//pat/str} ${name:off:len} ${name[n]} ${#name[@]}, A=(x y z) array assignment, $(...) command substitution, VAR=x cmd prefixes, ~ expansion, and POSIX-style path normalization (/tmp, /d/fooD:\foo).

Exit codes follow bash conventions: 0 ok, 1 fail, 2 usage/serious, 127 command not found, 124 timeout.

How it works

bash command ──parser──▶ AST ──translator──▶ PowerShell script ──executor──▶ selected PowerShell
                                                                              │
agent ◀── GNU-style output, bash-style errors ◀── UTF-8 framed host protocol ◀┘
  • Deterministic translation, zero LLM calls at runtime.

  • Each command maps to a generator that emits a self-contained PowerShell block honoring the "Fauxnix contract": string-per-line stdout, [Console]::Error.WriteLine for bash-style stderr, $script:fx_exit for exit codes, $input for stdin.

  • The executor wraps every script with UTF-8 enforcement ([Console]::OutputEncoding, $OutputEncoding, chcp 65001), decodes native output at the process boundary (UTF-8 by default or GBK(936) in ansi mode), keeps host frames UTF-8, strips CLIXML serialization and PowerShell noise from stderr, and rewrites common PowerShell errors (including zh-CN locale messages) into bash phrasing.

  • Scripts run via -EncodedCommand (UTF-16LE) and transparently fall back to a temp .ps1 file when the 32 KB command-line limit would be exceeded.

Known deviations (honest list)

fauxnix optimizes for the commands agents actually run. Documented deviations:

  • X=1 standalone assignments follow export semantics (one session-wide environment; bash's shell-var vs exported-var distinction does not exist), and a same-segment prefix is visible to $VAR inside the command's own words (Z=in [[ $Z == in ]] is true here, false in bash where word expansion precedes the temporary environment).

  • yes is capped at 65,536 lines — PS 5.1 pipelines cannot signal upstream producers to stop, so an unbounded yes | head would hang.

  • tail -f, eval, alias, heredocs, env -i/--ignore-environment, background &, and output/fd redirects (> >> 2> 2>> &> &>> 2>&1 1>&2) on a non-last pipeline stage (echo hi >f | cat) are rejected with operation-specific, actionable error messages instead of misbehaving. Per-stage < remains supported; fully routed per-stage output fds are still tracked by #157. (if/then/elif/else/fi, for x in ..., while/until, case ... esac (;; only; ;&/;;& fail loud), backtick substitution, command -v, pipeline read, dotenv-style source, word-level $((...)) arithmetic expansion, A=(x y z) arrays, and ${name//pat/str} / ${name:off:len} are supported.)

  • command -v <builtin> prints /usr/bin/<name> where bash prints the bare builtin name; exit codes and empty-result semantics match.

  • chmod maps only the read-only bit; exec bits are no-ops on Windows. chown is a silent no-op (as in Git Bash).

  • ps aux columns are approximations (no per-process CPU% accounting, USER shows ?).

  • gzip -c/pipeline stdin is text-faithful, not byte-faithful; file-mode gzip f is byte-exact.

  • A pipeline producing exactly one line, piped into wc -l, counts that line (bash would count 0 if the producer omitted the trailing newline). printf 'x' | md5sum stays byte-exact.

  • sed/awk support the common subset; hold-space, labels, arrays, loops throw named "not supported" errors at translate time.

  • curl/wget refuse loopback/private/reserved addresses (localhost, 127.x, ::1, 10.x, 172.16–31.x, 192.168.x, 169.254.x) as a safety default for agent-driven HTTP.

  • Native-tool pipelines vs encoding: PS 5.1 has a single console-encoding knob, so piping localized admin tools (ipconfig, tasklist — GBK on zh-CN) and UTF-8-native dev tools (node, curl) cannot both decode cleanly mid-pipeline. Default favors UTF-8 dev tools; set FAUXNIX_NATIVE_ENCODING=ansi when your agents grep Chinese output of native Windows admin tools. File reads are always sniffed per file (UTF-8 strict → GBK fallback), so grep/sed/awk over GBK files works in either mode — unlike Git Bash, which only matches the encoding its locale assumes.

Development

npm install
npm test          # unit + real-PowerShell integration suite (Windows only, auto-skipped elsewhere)
$env:FAUXNIX_PS = 'pwsh'; npm test   # same suite through PowerShell 7
npm run build
npx tsx scratch/run.mjs "any bash command"   # quick live check

Differential vs Git Bash is opt-in (FAUXNIX_DIFF_ORACLE=1; skips if unset or bash.exe is missing — Git Bash is not required). See test/differential/README.md. The 253-case corpus enforces the RFC C-7 minimum of 200 cases and a 95% identity gate. The weekly oracle runs from .github/workflows/differential.yml; two consecutive green scheduled runs are still required release evidence after this gate lands.

Architecture map: src/parser.ts (bash subset → AST) · src/translator.ts (AST → PowerShell + executor wrapper) · src/executor.ts (spawn, redirects, session persistence) · src/commands/*.ts (per-command generators) · src/mcp.ts (MCP server) · src/cli.ts.

Roadmap: docs/rfc-roadmap-to-1.0.md — tracks, milestones, and the RFC process for proposing waves.

Security

Trust model, host protocol, kill semantics, network guard, and reporting: SECURITY.md.

License

MIT © 20000419

Available Tools

3 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 ~), command substitution $(...), and 108+ 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, while/until/case, env -i/--ignore-environment, background jobs. if/then/elif/else/fi, for-in loops, and word-level $((...)) arithmetic expansion are supported.

CWD, environment variables, export/unset and cd 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. 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.7/5.0
Behavior5/5

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

Annotations are sparse (destructiveHint true, openWorldHint true). The description adds extensive behavioral detail: deterministic translation to PowerShell, output formatting, encoding handling, persistence of CWD/env across calls, bash-style exit codes, structuredContent return, and platform requirements. This far exceeds what annotations alone offer, with no contradiction.

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?

Although the description is long, every sentence delivers critical information: execution method, supported/unsupported features, state persistence, exit codes, structured output, and platform constraints. It is well-structured with clear sections and front-loads the core purpose. No redundant or filler content.

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?

This is a complex tool (command execution with many edge cases), and the description covers all critical aspects: translation behavior, supported commands, unsupported constructs, state persistence, exit code semantics, structured content fields, and platform requirements. Even though no output schema is provided, the description explicitly enumerates the structuredContent fields. Nothing essential is missing.

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% (both command and timeout_ms have descriptions). The description adds no extra parameter semantics beyond what the schema already states, such as the default timeout. Baseline of 3 is appropriate since the schema fully documents the parameters.

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 first sentence states a specific action ('Execute a Linux/bash-style command') on a specific platform ('this Windows machine'). It clearly distinguishes itself from siblings like fauxnix_translate (presumably a translation utility) and fauxnix_session (session management). No ambiguity about what the tool does.

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 explicitly lists what is supported (pipes, redirections, variables, 108+ coreutils commands) and what is not (heredocs, while/until, env -i, background jobs). It also clarifies that unknown commands (git, node, etc.) are passed through natively. This gives concrete when-to-use and when-not-to-use guidance beyond the schema.

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, session id). Actions: "status" (default) or "reset".

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

TDQS

A4.3/5.0
Behavior4/5

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

The description explains the effects of each action: status shows session state (cwd, tracked env keys), reset clears to a fresh shell. This enriches the idempotentHint=true and destructiveHint=false annotations by describing what actually changes.

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?

A single front-loaded sentence plus a brief action list. Every word is informative with no filler. Ideal conciseness.

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 the simple tool (one enum parameter, no output schema), the description fully covers the tool's purpose and behavior. The combination of description and schema leaves no meaningful gaps for an agent.

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% with a detailed enum description. The tool description reiterates the action names but adds no new semantic information beyond the schema. Baseline of 3 is appropriate.

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 inspects or resets a persistent fauxnix shell session, with specific actions enumerated. This distinctly differentiates it from sibling tools bash (executing commands) and fauxnix_translate (translations).

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 implies when to use this tool (for session state inspection or reset) but does not explicitly contrast with sibling tools or provide when-not guidance. The clarity of purpose and sibling names indirectly guide selection.

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. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedbash
    • First observedfauxnix_session
    • First observedfauxnix_translate

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a distinct purpose: execute, translate without executing, and manage session state. There is no overlap in functionality, so an agent can unambiguously select the right tool.

Naming Consistency4/5

Two tools follow a 'fauxnix_' prefix pattern, but the primary tool is simply named 'bash', which breaks the convention. However, this is a deliberate choice for the main entry point and all names are clear and predictable.

Tool Count5/5

With only 3 tools, the server is tightly scoped to its core purpose: executing bash commands, providing translation for debugging, and managing the session. No redundant tools; each earns its place.

Completeness5/5

The toolset covers the full lifecycle of the domain: execution (bash), understanding/debugging (fauxnix_translate), and session management (fauxnix_session). There are no obvious gaps for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Related MCP Connectors

Related MCP Servers

  • 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.
    -
  • 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.
    8
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/20000419/fauxnix'

If you have feedback or need assistance with the MCP directory API, please join our Discord server