mcp-server-commands

mcp-server-commands is a Model Context Protocol (MCP) server whose core purpose is to let large language models run commands and scripts on the host.

Main capabilities:

• Provides the runProcess tool for running processes. Currently there is only one command tool.
• Supports two mutually exclusive invocation methods:
  1. command_line (string): Executed through the system default shell, similar to manually typing in bash, fish, pwsh, etc., supporting shell features such as pipes, redirection, and variable expansion.
  2. argv (string array): Directly invokes an executable file, where argv[0] is the executable file and the rest are arguments, with no shell interpretation. The two cannot be passed at the same time; the tool infers whether to use the shell based on the provided arguments.
• Returns STDOUT and STDERR text.
• Optional stdin parameter: The model can pass scripts to commands such as fish, bash, zsh, and python via STDIN, and can also create files from stdin text via cat >> foo/bar.txt.

Usage:

• This server is implemented via STDIO transport. If HTTP is needed, mcpo can be used to provide an OpenAPI-compatible web server interface, and it can be used with Open-WebUI.
• When used with Claude Desktop, the server configuration must be added to the configuration file: the macOS path is ~/Library/Application Support/Claude/claude_desktop_config.json, and the Windows path is %APPDATA%/Claude/claude_desktop_config.json. Groq Desktop (beta, macOS) uses ~/Library/Application Support/groq-desktop-app/settings.json.
• The published npm package mcp-server-commands can be used, or a local build (repository checkout) can be used; a local build requires running npm run build.
• Automatic rebuild is supported during development.
• The model may not proactively consider itselfable to run commands; system prompts or prompt templates can be used to guide the model to follow user requests, including directly using runProcess without repeated confirmation.
• If you want the model to use a specific shell, it is recommended to list it in the system prompt, because the model pays more attention to examples in the system prompt.
• For scenarios where the model is run locally, consider using Ollama (with Open-WebUI).
• For debugging, because the MCP server communicates over stdio, debugging can be difficult; MCP Inspector is recommended (available via package scripts), and it provides a URL to access the debugging tool in a browser.
• For logging, Claude Desktop writes logs to ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log; by default only important messages (such as errors) are logged. If more messages are needed, add --verbose to args when configuring the server. Logs are written to STDERR because Claude Desktop routes it to the log file.

Applicable scenarios:

• Letting the LLM execute commands on the host, such as hostname, ls -al, echo "hello world", etc.
• Passing scripts to a shell or python for execution via STDIN.
• Creating files from stdin content.
• Claude Sonnet 3.5 has been tested and can intelligently use run_process; preliminary tests show that Groq Desktop with MCP and the llama4 model also produces good results.

Limitations and caveats:

• This is a learning exercise, essentially a "user-requested tool invocation" template for running commands and passing the output to the model.
• Security warning: Be cautious about the commands this server is allowed to run. Permissions are determined by the user running the server; do not run it with sudo. In the Claude Desktop app, it is recommended to use Approve Once (rather than Allow for This Chat) so that commands can be reviewed one by one, and to use Deny if a command is not trusted.
• When using mcpo with open-webui, you must review the security risks yourself.
• The documentation does not provide specific installation commands, build command details, or fee or pricing information, and none is currently provided.