mcp-server-commands
The mcp-server-commands server allows LLMs to execute system commands and scripts on the host machine, enabling interaction with the local environment.
Execute Commands: Run shell commands (e.g.,
hostname,ls,echo) using therun_commandmethod, which returnsSTDOUTandSTDERRInput Support: Provide input to commands via
stdinparameter for interactive programs likebashorpythonRun Scripts: Execute scripts by piping them to a specified interpreter (bash, python, etc.)
Working Directory: Specify the working directory for command and script execution
Integration with LLMs: Designed for use with models like Claude Sonnet 3.5, with command review capabilities in the Claude Desktop app
Development Tools: Includes debugging and logging features such as the MCP Inspector
Provides system command execution capabilities on macOS, with specific installation paths for the Claude Desktop app configuration on macOS systems.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-server-commandslist files in the current directory"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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!
Related MCP server: cargo-mcp
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"etcReturns
STDOUTandSTDERRas textOptional
stdinparameter means your LLM canpass scripts over
STDINto commands likefish,bash,zsh,pythoncreate files with
cat >> foo/bar.txtfrom the text instdin
Be careful what you ask this server to run!
In Claude Desktop app, useApprove Once (not Allow for This Chat) so you can review each command, use Deny if you don't trust the command.
Permissions are dictated by the user that runs the server.
DO NOT run with sudo.
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 installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchInstallation
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-coderHTTP / 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 <=> HTTPI briefly usedmcpo with open-webui, make sure to vet it for security concerns.
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 inspectorThe Inspector will provide a URL to access debugging tools in your browser.
Available Tools
1 toolrun_processB
Run a process on this linux machine
| Name | Required | Description | Default |
|---|---|---|---|
| command_line | No | Shell mode: a shell command line executed via the system's default shell. Supports pipes, redirects, globbing. Cannot be combined with 'argv'. | |
| argv | No | Executable mode: directly spawn a process. argv[0] is the executable, followed by arguments passed verbatim (no shell interpretation). Cannot be combined with 'command_line'. | |
| cwd | No | Optional to set working directory | |
| stdin_text | No | Optional text written to STDIN (written fully, then closed). Useful for heredoc-style input or file contents. | |
| timeout_ms | No | Optional timeout in milliseconds, defaults to 30,000ms |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It only states 'Run a process' without disclosing that it executes shell commands (which could be dangerous), blocks until completion, or handles errors. The lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff. It is front-loaded and efficient. Could be slightly more informative without harm, but current length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist. The description fails to mention return values, error behavior, or success/failure indicators. For a command execution tool, this is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains each parameter. The description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource ('Run a process on this linux machine'). The verb 'run' and noun 'process' are specific. No siblings exist, so differentiation isn't needed. Slight lack of detail about the two execution modes (shell vs. argv) prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not-to-use guidance is provided. However, the tool is standalone with no siblings, and the description implies it's for executing arbitrary processes. This is minimally adequate.
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.
2 tool updates
v0.8.2- Removed
run_command - Added
run_process
1 tool update
v1.0.0- Added
run_command
TDQS
Only one tool exists, so there is no possibility of ambiguity.
With a single tool, naming is trivially consistent. The tool name 'run_process' follows a clear verb_noun pattern.
A server named 'commands' with only one tool is too few; it suggests the scope is not well-captured.
The server only supports running a process, lacking essential operations like listing, managing, or stopping processes, which are significant gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server for deep research or task groups
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server allowing any and all command execution over CMD218125MIT
- Apache 2.0
- AlicenseAqualityCmaintenanceAn MCP server for interacting with Discord.1934811MIT
- AGPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/g0t4/mcp-server-commands'
If you have feedback or need assistance with the MCP directory API, please join our Discord server