Skip to main content
Glama
g0t4

mcp-server-commands

by g0t4

runProcess 도구

runProcess 도구는 호스트 머신에서 프로세스를 실행합니다. 이를 호출하는 방법은 상호 배타적인 두 가지가 있습니다:

  1. command_line (문자열) — 시스템의 기본 셸을 통해 실행됩니다(bash/fish/pwsh 등에 입력하는 것과 동일). 파이프, 리다이렉트, 변수 확장과 같은 셸 기능이 모두 작동합니다.

  2. argv (문자열 배열) — 직접 실행 파일을 호출합니다. argv[0]은 실행 파일이며, 나머지는 인수입니다. 셸 해석이 없습니다.

두 가지를 동시에 전달할 수는 없습니다. 도구는 제공한 매개변수를 통해 셸 사용 여부를 추론합니다.

모델이 시스템에서 특정 셸을 사용하도록 하려면 시스템 프롬프트에 나열하는 것이 좋습니다. 또는 도구 지침에 포함할 수도 있지만, 모델은 시스템 프롬프트의 예시에 더 주의를 기울이는 경향이 있습니다.

문제가 발생하면 알려주세요!

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이 다음을 수행할 수 있음

      • fish, bash, zsh, python과 같은 명령어에 STDIN을 통해 스크립트 전달

      • stdin의 텍스트를 사용하여 cat >> foo/bar.txt로 파일 생성

[!WARNING] 이 서버가 실행하도록 요청하는 내용에 주의하세요! Claude Desktop 앱에서는 각 명령어를 검토할 수 있도록 Approve Once(이 채팅에 대해 허용 아님)를 사용하고, 명령어를 신뢰할 수 없는 경우 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 (베타, macOS)은 ~/Library/Application Support/groq-desktop-app/settings.json을 사용합니다.

게시된 npm 패키지 사용

이 워크플로우를 사용하여 mcp-server-commands로 npm에 게시되었습니다.

{
  "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의 경우, OpenAPI 호환 웹 서버 인터페이스를 위해 mcpo를 사용하세요. 이는 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] open-webui와 함께 mcpo를 잠시 사용해 보았는데, 보안 문제를 확인하시기 바랍니다.

로깅

Claude Desktop 앱은 로그를 ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log에 기록합니다.

기본적으로 중요한 메시지(예: 오류)만 기록됩니다. 더 많은 메시지를 보려면 서버 구성 시 args에 --verbose를 추가하세요.

참고로, 로그는 Claude Desktop이 로그 파일로 라우팅하는 STDERR로 기록됩니다. 향후에는 잘 형식화된 로그 메시지가 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

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

Related MCP Connectors

Related MCP Servers