Skip to main content
Glama
g0t4

mcp-server-commands

by g0t4

Herramienta runProcess

La herramienta runProcess ejecuta procesos en la máquina anfitriona. Existen dos formas mutuamente excluyentes de invocarla:

  1. command_line (cadena) — Ejecutado a través del shell predeterminado del sistema (igual que escribir en bash/fish/pwsh/etc). Las funciones del shell como tuberías (pipes), redirecciones y expansión de variables funcionan correctamente.

  2. argv (matriz de cadenas) — Invocación directa del ejecutable. argv[0] es el ejecutable, el resto son argumentos. Sin interpretación del shell.

No puedes pasar ambos. La herramienta infiere si debe usar un shell a partir del parámetro que proporciones.

Si deseas que tu modelo utilice shells específicos en un sistema, te recomiendo listarlos en tu prompt del sistema. O quizás en las instrucciones de tu herramienta, aunque los modelos tienden a prestar más atención a los ejemplos en un prompt del sistema.

¡Avísame si encuentras algún problema!

Related MCP server: cargo-mcp

Herramientas

Las herramientas son para que los LLM las soliciten. Claude Sonnet 3.5 utiliza run_process de forma inteligente. Además, las pruebas iniciales muestran resultados prometedores con Groq Desktop with MCP y modelos llama4.

Actualmente, ¡solo un comando para gobernarlos a todos!

  • run_process - ejecuta un comando, p. ej. hostname o ls -al o echo "hello world" etc.

    • Devuelve STDOUT y STDERR como texto

    • El parámetro opcional stdin significa que tu LLM puede

      • pasar scripts a través de STDIN a comandos como fish, bash, zsh, python

      • crear archivos con cat >> foo/bar.txt a partir del texto en stdin

[!WARNING] ¡Ten cuidado con lo que le pides a este servidor que ejecute! En la aplicación Claude Desktop, usa Approve Once (no Allow for This Chat) para que puedas revisar cada comando, usa Deny si no confías en el comando. Los permisos están dictados por el usuario que ejecuta el servidor. NO ejecutes con sudo.

Tutorial en video

Prompts

Los prompts son para que los usuarios los incluyan en el historial del chat, p. ej. mediante los comandos de barra diagonal de Zed (en su panel de AI Chat)

  • run_process - genera un mensaje de prompt con la salida del comando

  • Para tu información, esto fue principalmente un ejercicio de aprendizaje... Veo esto como una llamada de herramienta solicitada por el usuario. ¡Esa es una forma elegante de decir que es una plantilla para ejecutar un comando y pasar las salidas al modelo!

Desarrollo

Instalar dependencias:

npm install

Construir el servidor:

npm run build

Para desarrollo con reconstrucción automática:

npm run watch

Instalación

Para usar con Claude Desktop, añade la configuración del servidor:

En MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json En Windows: %APPDATA%/Claude/claude_desktop_config.json

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

Usar el paquete npm publicado

Publicado en npm como mcp-server-commands usando este flujo de trabajo

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

Usar una compilación local (repositorio clonado)

Asegúrate de ejecutar npm run build

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

Modelos locales

  • La mayoría de los modelos están entrenados de tal manera que no creen que pueden ejecutar comandos por ti.

    • A veces, usan herramientas sin dudarlo... otras veces, tengo que convencerlos.

    • Usa un prompt del sistema o una plantilla de prompt para indicar que deben seguir las solicitudes del usuario. Incluyendo el uso de run_process sin verificar dos veces.

  • Ollama es una excelente manera de ejecutar un modelo localmente (con 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

El servidor está implementado con el transporte STDIO. Para HTTP, usa mcpo para una interfaz de servidor web compatible con OpenAPI. Esto funciona con 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] He usado brevemente mcpo con open-webui, asegúrate de verificarlo por problemas de seguridad.

Registro (Logging)

La aplicación Claude Desktop escribe registros en ~/Library/Logs/Claude/mcp-server-mcp-server-commands.log

Por defecto, solo se registran los mensajes importantes (p. ej. errores). Si deseas ver más mensajes, añade --verbose a los args al configurar el servidor.

Por cierto, los registros se escriben en STDERR porque eso es lo que Claude Desktop enruta a los archivos de registro. En el futuro, espero que los mensajes de registro bien formateados se escriban a través del transporte STDIO al cliente MCP (nota: no a la aplicación Claude Desktop).

Depuración

Dado que los servidores MCP se comunican a través de stdio, la depuración puede ser un desafío. Recomendamos usar el MCP Inspector, que está disponible como un script del paquete:

npm run inspector

El Inspector proporcionará una URL para acceder a las herramientas de depuración en tu navegador.

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