Execute Terminal Commands via LLM
MCP server that runs shell commands or direct executables on the host machine, returning stdout and stderr, with an optional stdin for scripts.
0.8.2Add to Favorites
Why it matters
Empower Large Language Models to interact directly with your system by executing terminal commands. This asset bridges the gap between AI and command-line operations, allowing for automated system management and task execution.
Outcomes
What it gets done
Execute arbitrary terminal commands with LLM input.
Process STDOUT and STDERR for command results.
Pass code to interpreters like bash, python, and fish.
Create files programmatically using commands like 'cat'.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-commands | bash Capabilities
Tools your agent gets
Executes terminal commands and returns STDOUT and STDERR output with optional stdin parameter.
Overview
commands MCP server
An MCP server exposing a single run_process tool that executes a shell command or a direct executable on the host machine, optionally piping a script over stdin, and returns stdout and stderr as text. Use it when an AI assistant needs to actually run a command on the host, but only with per-command approval in the client, never with sudo, since it can execute anything the running user can.
What it does
An MCP server built around a single tool, run_process, that runs a command on the host machine and returns its stdout and stderr as text. It supports two mutually exclusive invocation styles: command_line, a string executed through the system's default shell so pipes, redirects, and variable expansion all work as if typed directly into bash, fish, or PowerShell, or argv, a string array that invokes an executable directly with no shell interpretation, where the first element is the executable and the rest are its arguments. An optional stdin parameter lets a script be piped into an interpreter like bash, fish, or python, or lets output be redirected into a new file via a command like cat >> foo/bar.txt.
When to use - and when NOT to
Use it when an AI assistant genuinely needs to run something on the host - checking hostname, listing files, piping a short script to an interpreter - rather than simulating command output from memory. Because it will run whatever it's asked to run, the project's own guidance is explicit: in Claude Desktop, use Approve Once rather than Allow for This Chat so every command gets reviewed individually, deny anything untrusted, and never run the server with sudo, since permissions are inherited from whichever user runs it. Local, less capable models often need an explicit system-prompt instruction that they are allowed to use run_process without hesitating or double-checking, since many are trained to assume they cannot execute commands at all.
Capabilities
The tool layer is just run_process, taking either command_line or argv, never both, the presence of one determines whether a shell is used, and an optional stdin string, returning STDOUT and STDERR as text. A companion prompt, also named run_process, generates a chat-history message from a command's output for clients like Zed that support MCP prompts via slash commands. The server runs over stdio by default; for an HTTP or OpenAPI-compatible interface, such as with Open-WebUI, it can be bridged with the third-party tool mcpo.
How to install
{
"mcpServers": {
"mcp-server-commands": {
"command": "npx",
"args": ["mcp-server-commands"]
}
}
}
Add this to Claude Desktop's config file, or Groq Desktop's settings.json on macOS, which has shown promising results with llama4 models. For an HTTP interface:
uvx mcpo --port 3010 --api-key "supersecret" -- npx mcp-server-commands
Who it's for
Developers and power users who want an AI assistant that can actually execute commands on their machine - system inspection, quick scripts, local automation - and who will personally review each command before approving it, given the server can run anything the host user is permitted to run.
Source README
runProcess tool
The runProcess tool runs processes on the host machine. There are two mutually exclusive ways to invoke it:
command_line(string) - Executed via the system's default shell (just like typing intobash/fish/pwsh/etc). Shell features like pipes, redirects, and variable expansion all work.argv(string array) - Direct executable invocation.argv[0]is the executable, the rest are arguments. No shell interpretation.
You cannot pass both. The tool infers whether to use a shell from which parameter you provide.
If you want your model to use specific shell(s) on a system, I would list them in your system prompt. Or, maybe in your tool instructions, though models tend to pay better attention to examples in a system prompt.
Let me know if you encounter problems!
Tools
Tools are for LLMs to request. Claude Sonnet 3.5 intelligently uses run_process. And, initial testing shows promising results with Groq Desktop with MCP and llama4 models.
Currently, just one command to rule them all!
run_process- run a command, i.e.hostnameorls -alorecho "hello world"etc- Returns
STDOUTandSTDERRas text - Optional
stdinparameter means your LLM can- pass scripts over
STDINto commands likefish,bash,zsh,python - create files with
cat >> foo/bar.txtfrom the text instdin
- pass scripts over
- Returns
Video walkthrough
Prompts
Prompts are for users to include in chat history, i.e. via Zed's slash commands (in its AI Chat panel)
run_process- generate a prompt message with the command output
- FYI this was mostly a learning exercise... I see this as a user requested tool call. That's a fancy way to say, it's a template for running a command and passing the outputs to the model!
Development
Install dependencies:
npm install
Build the server:
npm run build
For development with auto-rebuild:
npm run watch
Installation
To use with Claude Desktop, add the server config:
On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
Groq Desktop (beta, macOS) uses ~/Library/Application Support/groq-desktop-app/settings.json
Use the published npm package
Published to npm as mcp-server-commands using this workflow
{
"mcpServers": {
"mcp-server-commands": {
"command": "npx",
"args": ["mcp-server-commands"]
}
}
}
Use a local build (repo checkout)
Make sure to run npm run build
{
"mcpServers": {
"mcp-server-commands": {
// works b/c of shebang in index.js
"command": "/path/to/mcp-server-commands/build/index.js"
}
}
}
Local Models
- Most models are trained such that they don't think they can run commands for you.
- Sometimes, they use tools w/o hesitation... other times, I have to coax them.
- Use a system prompt or prompt template to instruct that they should follow user requests. Including to use
run_processswithout double checking.
- Ollama is a great way to run a model locally (w/ Open-WebUI)
# NOTE: make sure to review variants and sizes, so the model fits in your VRAM to perform well!
# Probably the best so far is [OpenHands LM](https://www.all-hands.dev/blog/introducing-openhands-lm-32b----a-strong-open-coding-agent-model)
ollama pull https://huggingface.co/lmstudio-community/openhands-lm-32b-v0.1-GGUF
# https://ollama.com/library/devstral
ollama pull devstral
# Qwen2.5-Coder has tool use but you have to coax it
ollama pull qwen2.5-coder
HTTP / OpenAPI
The server is implemented with the STDIO transport.
For HTTP, use mcpo for an OpenAPI compatible web server interface.
This works with Open-WebUI
uvx mcpo --port 3010 --api-key "supersecret" -- npx mcp-server-commands
# uvx runs mcpo => mcpo run npx => npx runs mcp-server-commands
# then, mcpo bridges STDIO <=> HTTP
Logging
Claude Desktop app writes logs to ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log
By default, only important messages are logged (i.e. errors).
If you want to see more messages, add --verbose to the args when configuring the server.
By the way, logs are written to STDERR because that is what Claude Desktop routes to the log files.
In the future, I expect well formatted log messages to be written over the STDIO transport to the MCP client (note: not Claude Desktop app).
Debugging
Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:
npm run inspector
The Inspector will provide a URL to access debugging tools in your browser.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.
