Skip to main content
Glama
deenesjakoruzh
g0t4

mcp-server-commands

by g0t4
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

runProcess 工具

runProcess 工具用于在宿主机上运行进程。有两种互斥的调用方式：

  1. command_line (字符串) — 通过系统的默认 shell 执行（就像在 bash/fish/pwsh 等中输入一样）。shell 的特性（如管道、重定向和变量扩展）均可使用。

  2. argv (字符串数组) — 直接执行可执行文件。argv[0] 是可执行文件，其余为参数。不进行 shell 解析。

你不能同时传递两者。该工具会根据你提供的参数推断是否使用 shell。

如果你希望模型在系统上使用特定的 shell，建议在系统提示词（system prompt）中列出它们。或者也可以放在工具说明中，尽管模型往往更关注系统提示词中的示例。

如果遇到问题，请告诉我！

Related MCP server: cargo-mcp

工具

工具供 LLM 请求使用。Claude Sonnet 3.5 可以智能地使用 run_process。初步测试显示，Groq Desktop with MCP 和 llama4 模型的效果也很不错。

目前，只有一个命令可以统领一切！

  • run_process - 运行命令，例如 hostname 或 ls -al 或 echo "hello world" 等

    • 以文本形式返回 STDOUT 和 STDERR

    • 可选的 stdin 参数意味着你的 LLM 可以

      • 通过 STDIN 将脚本传递给 fish、bash、zsh、python 等命令

      • 使用 stdin 中的文本通过 cat >> foo/bar.txt 创建文件

[!WARNING] 请谨慎对待你要求此服务器运行的命令！ 在 Claude Desktop 应用中，请使用 Approve Once（不要使用 Allow for This Chat），以便你可以审查每个命令；如果你不信任该命令，请使用 Deny。 权限由运行服务器的用户决定。 请勿使用 sudo 运行。

视频演示

提示词

提示词供用户包含在聊天记录中，例如通过 Zed 的斜杠命令（在其 AI 聊天面板中）

  • run_process - 生成带有命令输出的提示消息

  • 顺便说一下，这主要是一个学习练习……我认为这是一个用户请求的工具调用。换句话说，它是一个运行命令并将输出传递给模型的模板！

开发

安装依赖：

npm install

构建服务器：

npm run build

用于自动重新构建的开发模式：

npm run watch

安装

要与 Claude Desktop 一起使用，请添加服务器配置：

MacOS 上：~/Library/Application Support/Claude/claude_desktop_config.json Windows 上：%APPDATA%/Claude/claude_desktop_config.json

Groq Desktop (beta, macOS) 使用 ~/Library/Application Support/groq-desktop-app/settings.json

使用已发布的 npm 包

已发布到 npm，名称为 mcp-server-commands，使用此 工作流

{
  "mcpServers": {
    "mcp-server-commands": {
      "command": "npx",
      "args": ["mcp-server-commands"]
    }
  }
}

使用本地构建（仓库检出）

确保运行 npm run build

{
  "mcpServers": {
    "mcp-server-commands": {
      // works b/c of shebang in index.js
      "command": "/path/to/mcp-server-commands/build/index.js"
    }
  }
}

本地模型

  • 大多数模型经过训练，认为它们无法为你运行命令。

    • 有时，它们会毫不犹豫地使用工具……而有时，我必须诱导它们。

    • 使用系统提示词或提示词模板来指示它们应该遵循用户请求。包括在不进行二次确认的情况下使用 run_process。

  • Ollama 是在本地运行模型（配合 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

该服务器使用 STDIO 传输实现。 对于 HTTP，请使用 mcpo 获取 OpenAPI 兼容的 Web 服务器接口。 这适用于 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] 我曾短暂地将 mcpo 与 open-webui 一起使用，请务必审查其安全隐患。

日志记录

Claude Desktop 应用将日志写入 ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log

默认情况下，仅记录重要消息（即错误）。 如果你想查看更多消息，请在配置服务器时向 args 添加 --verbose。

顺便说一下，日志被写入 STDERR，因为这是 Claude Desktop 路由到日志文件的内容。 将来，我期望格式良好的日志消息能够通过 STDIO 传输写入 MCP 客户端（注意：不是 Claude Desktop 应用）。

调试

由于 MCP 服务器通过 stdio 进行通信，调试可能具有挑战性。我们建议使用 MCP Inspector，它作为包脚本提供：

npm run inspector

Inspector 将提供一个 URL，用于在浏览器中访问调试工具。

Available Tools

1 tool
run_processB

Run a process on this linux machine

ParametersJSON Schema
NameRequiredDescriptionDefault
command_lineNoShell mode: a shell command line executed via the system's default shell. Supports pipes, redirects, globbing. Cannot be combined with 'argv'.
argvNoExecutable mode: directly spawn a process. argv[0] is the executable, followed by arguments passed verbatim (no shell interpretation). Cannot be combined with 'command_line'.
cwdNoOptional to set working directory
stdin_textNoOptional text written to STDIN (written fully, then closed). Useful for heredoc-style input or file contents.
timeout_msNoOptional timeout in milliseconds, defaults to 30,000ms

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updatesv0.8.2
    • Removedrun_command
    • Addedrun_process
  2. 1 tool updatev1.0.0
    • Addedrun_command
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity.

Naming Consistency5/5

With a single tool, naming is trivially consistent. The tool name 'run_process' follows a clear verb_noun pattern.

Tool Count2/5

A server named 'commands' with only one tool is too few; it suggests the scope is not well-captured.

Completeness2/5

The server only supports running a process, lacking essential operations like listing, managing, or stopping processes, which are significant gaps.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches