mcp-server-commands
runProcess-Tool
Das runProcess-Tool führt Prozesse auf dem Host-Rechner aus. Es gibt zwei sich gegenseitig ausschließende Möglichkeiten, es aufzurufen:
command_line(Zeichenkette) — Wird über die Standard-Shell des Systems ausgeführt (genau wie die Eingabe inbash/fish/pwsh/etc.). Shell-Funktionen wie Pipes, Umleitungen und Variablenexpansion funktionieren alle.argv(Zeichenketten-Array) — Direkter Aufruf einer ausführbaren Datei.argv[0]ist die ausführbare Datei, der Rest sind Argumente. Keine Shell-Interpretation.
Sie können nicht beides übergeben. Das Tool leitet anhand des bereitgestellten Parameters ab, ob eine Shell verwendet werden soll.
Wenn Sie möchten, dass Ihr Modell bestimmte Shells auf einem System verwendet, würde ich diese in Ihrem System-Prompt auflisten. Oder vielleicht in Ihren Tool-Anweisungen, obwohl Modelle dazu neigen, Beispielen in einem System-Prompt mehr Aufmerksamkeit zu schenken.
Lassen Sie mich wissen, wenn Sie auf Probleme stoßen!
Related MCP server: cargo-mcp
Tools
Tools sind für LLMs zum Anfordern gedacht. Claude Sonnet 3.5 verwendet run_process intelligent. Und erste Tests zeigen vielversprechende Ergebnisse mit Groq Desktop mit MCP und llama4-Modellen.
Derzeit gibt es nur einen Befehl, der sie alle beherrscht!
run_process- führt einen Befehl aus, z. B.hostnameoderls -aloderecho "hello world"usw.Gibt
STDOUTundSTDERRals Text zurückDer optionale
stdin-Parameter bedeutet, dass Ihr LLMSkripte über
STDINan Befehle wiefish,bash,zsh,pythonübergeben kannDateien mit
cat >> foo/bar.txtaus dem Text instdinerstellen kann
[!WARNING] Seien Sie vorsichtig, was Sie diesen Server ausführen lassen! Verwenden Sie in der Claude Desktop-App "Einmal genehmigen" (nicht "Für diesen Chat erlauben"), damit Sie jeden Befehl überprüfen können. Verwenden Sie "Ablehnen", wenn Sie dem Befehl nicht vertrauen. Die Berechtigungen werden durch den Benutzer bestimmt, der den Server ausführt. Führen Sie ihn NICHT mit
sudoaus.
Video-Walkthrough
Prompts
Prompts sind für Benutzer gedacht, die sie in den Chatverlauf einfügen können, z. B. über Zeds Slash-Befehle (im AI-Chat-Panel)
run_process- generiert eine Prompt-Nachricht mit der Befehlsausgabe
Zur Info: Dies war hauptsächlich eine Lernübung... Ich sehe dies als ein vom Benutzer angefordertes Tool-Call. Das ist eine schicke Art zu sagen, es ist eine Vorlage zum Ausführen eines Befehls und zum Weiterleiten der Ausgaben an das Modell!
Entwicklung
Abhängigkeiten installieren:
npm installServer bauen:
npm run buildFür die Entwicklung mit automatischem Neuaufbau:
npm run watchInstallation
Um es mit Claude Desktop zu verwenden, fügen Sie die Serverkonfiguration hinzu:
Unter MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Unter Windows: %APPDATA%/Claude/claude_desktop_config.json
Groq Desktop (Beta, macOS) verwendet ~/Library/Application Support/groq-desktop-app/settings.json
Verwenden des veröffentlichten npm-Pakets
Veröffentlicht auf npm als mcp-server-commands unter Verwendung dieses Workflows
{
"mcpServers": {
"mcp-server-commands": {
"command": "npx",
"args": ["mcp-server-commands"]
}
}
}Verwenden eines lokalen Builds (Repo-Checkout)
Stellen Sie sicher, dass Sie npm run build ausführen
{
"mcpServers": {
"mcp-server-commands": {
// works b/c of shebang in index.js
"command": "/path/to/mcp-server-commands/build/index.js"
}
}
}Lokale Modelle
Die meisten Modelle sind so trainiert, dass sie nicht glauben, sie könnten Befehle für Sie ausführen.
Manchmal verwenden sie Tools ohne Zögern... andere Male muss ich sie dazu überreden.
Verwenden Sie einen System-Prompt oder eine Prompt-Vorlage, um anzuweisen, dass sie Benutzeranfragen befolgen sollen. Einschließlich der Verwendung von
run_processohne doppelte Überprüfung.
Ollama ist eine großartige Möglichkeit, ein Modell lokal auszuführen (mit 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
Der Server ist mit dem STDIO-Transport implementiert.
Für HTTP verwenden Sie mcpo für eine OpenAPI-kompatible Webserver-Schnittstelle.
Dies funktioniert mit 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[!WARNING] Ich habe
mcpokurz mitopen-webuiverwendet, stellen Sie sicher, dass Sie es auf Sicherheitsbedenken prüfen.
Protokollierung
Die Claude Desktop-App schreibt Protokolle nach ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log
Standardmäßig werden nur wichtige Meldungen protokolliert (z. B. Fehler).
Wenn Sie mehr Meldungen sehen möchten, fügen Sie --verbose zu den args hinzu, wenn Sie den Server konfigurieren.
Übrigens werden Protokolle in STDERR geschrieben, da Claude Desktop dies an die Protokolldateien weiterleitet.
In Zukunft erwarte ich, dass gut formatierte Protokollmeldungen über den STDIO-Transport an den MCP-Client geschrieben werden (Hinweis: nicht die Claude Desktop-App).
Debugging
Da MCP-Server über stdio kommunizieren, kann das Debugging eine Herausforderung sein. Wir empfehlen die Verwendung des MCP Inspector, der als Paket-Skript verfügbar ist:
npm run inspectorDer Inspector stellt eine URL bereit, um auf Debugging-Tools in Ihrem Browser zuzugreifen.
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.
2 tool updates
v0.8.2- Removed
run_command - Added
run_process
1 tool update
v1.0.0- Added
run_command
TDQS
Scored across 1 tool
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
Related MCP Connectors
An MCP server for deep research or task groups
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server allowing any and all command execution over CMD283 npm24MIT
- Apache 2.0
- AlicenseAqualityCmaintenanceAn MCP server for interacting with Discord.19155 npm11MIT
- AGPL 3.0