MCP Connector

Execute Terminal Commands via LLM

MCP server letting an AI assistant run shell commands or direct executables on the host machine, with per-command approval.

Works with ollamaclaude

Maintainer of this project? Claim this page to edit the listing.


91
Spark score
out of 100
Updated last month
Version 0.8.2
Models
claude 3 5 sonnetuniversal

Add 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

01

Execute arbitrary terminal commands with LLM input.

02

Process STDOUT and STDERR for command results.

03

Pass code to interpreters like bash, python, and fish.

04

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

run_command

Executes terminal commands and returns STDOUT and STDERR output with optional stdin parameter.

Overview

commands MCP server

An MCP server exposing a run_process tool that executes shell commands or direct executables on the host machine, returning STDOUT/STDERR. Use when an AI assistant needs to execute real commands on the host, always with per-command approval and never run as root.

What it does

This MCP server exposes a runProcess/run_process tool that runs processes on the host machine. It can be invoked two mutually exclusive ways: command_line (a string executed via the system's default shell, so pipes, redirects, and variable expansion all work, just like typing into bash/fish/pwsh) or argv (a string array for direct executable invocation with no shell interpretation, where argv[0] is the executable and the rest are arguments) - you cannot pass both, and the tool infers which mode to use from which parameter is supplied. The command returns STDOUT and STDERR as text, and an optional stdin parameter lets the calling model pipe scripts into interpreters like fish/bash/zsh/python, or create files via cat >> foo/bar.txt fed from stdin text.

When to use - and when NOT to

Use this connector when an AI assistant needs to actually execute commands on the host - running scripts, inspecting system state, or creating files via piped stdin. This is genuinely dangerous by design: the source's own warning says be careful what you ask the server to run, use "Approve Once" rather than "Allow for This Chat" in Claude Desktop so every command gets reviewed, use "Deny" for anything untrusted, remember permissions are whatever the user running the server has, and never run the server with sudo. If you want the model to prefer a specific shell, state it explicitly in the system prompt rather than tool instructions, since models pay closer attention to system-prompt examples.

Inputs and outputs

Install dependencies with npm install, build with npm run build, or use npm run watch for auto-rebuild during development. For Claude Desktop, configure the server in claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows: %APPDATA%/Claude/claude_desktop_config.json); Groq Desktop (beta, macOS) uses ~/Library/Application Support/groq-desktop-app/settings.json instead. Use the published npm package via npx mcp-server-commands, or point at a local repo build's build/index.js (which works via its shebang). A companion run_process prompt lets users (e.g. via Zed's slash commands) generate a chat message from a command's output - described by the author as mainly a learning exercise / template for running a command and passing its output to the model.

Integrations

Claude Sonnet 3.5 is reported to use run_process intelligently, and initial testing shows promising results with Groq Desktop (MCP-enabled beta) and Llama 4 models; local models are often reluctant to run commands without an explicit system-prompt instruction telling them to follow user requests without double-checking. For local models via Ollama, the source names OpenHands LM 32B, Devstral, and Qwen2.5-Coder (the latter needing coaxing to use tools) as options, noting to check variant/size against available VRAM. The server itself uses STDIO transport; for an HTTP/OpenAPI interface (e.g. for Open-WebUI), bridge it with mcpo (uvx mcpo --port 3010 --api-key "supersecret" -- npx mcp-server-commands), with an explicit warning to vet mcpo for security concerns before using it with open-webui. Claude Desktop logs to ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log (errors only by default; add --verbose for more), written to STDERR since that's what Claude Desktop routes to log files. Debugging is done via the MCP Inspector (npm run inspector), which provides a browser-based debugging URL.

Who it's for

Developers who want an AI assistant to execute real shell commands or scripts on their machine and are prepared to review every invocation individually (never auto-approving, never running as root) - not a fit for unattended or untrusted execution.

Source README

runProcess tool

The runProcess tool runs processes on the host machine. There are two mutually exclusive ways to invoke it:

  1. command_line (string) - Executed via the system's default shell (just like typing into bash/fish/pwsh/etc). Shell features like pipes, redirects, and variable expansion all work.
  2. 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. hostname or ls -al or echo "hello world" etc
    • Returns STDOUT and STDERR as text
    • Optional stdin parameter means your LLM can
      • pass scripts over STDIN to commands like fish, bash, zsh, python
      • create files with cat >> foo/bar.txt from the text in stdin

Video walkthrough

YouTube Thumbnail

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