Garita MCP

Detectar riesgo de inyección de comandos del sistema

detect_command_injection_risk

Analiza el código fuente de una herramienta MCP que ejecuta un comando del sistema operativo a partir de una entrada que le pasa el agente (un nombre de archivo, un argumento de búsqueda, un parámetro cualquiera) en busca de señales de riesgo de inyección de comandos: una llamada que SIEMPRE invoca una shell (exec, execSync, os.system, os.popen, shell_exec, passthru, system, y equivalentes) con un argumento que depende de una variable/entrada externa sin ninguna validación o escape reconocible cerca; una llamada que invoca una shell solo CONDICIONALMENTE (spawn/execFile de Node, subprocess.run/Popen/call de Python) únicamente cuando trae la opción shell:true/shell=True explícita — sin esa opción, un arreglo de argumentos se ejecuta directamente sin pasar por ningún intérprete de shell y no se marca como riesgo; el patrón "descargar y ejecutar" (curl/wget encadenado con una tubería directa a bash/sh); y ausencia de cualquier filtrado reconocible de metacaracteres de shell (;, &&, |, `, $(), >, <) — una lista de comandos permitidos que solo revisa el primer token del comando deja pasar cualquier cosa encadenada después de ese token, el patrón exacto detrás de CVE-2026-55581/55582 (mcp-shell, CVSS hasta 8.6). Motivada por ser la SEGUNDA categoría más grande de vulnerabilidades reales en un censo de 2026 sobre 9.695 servidores MCP escaneados: inyección de comandos fue el 9.6% de los 4.982 problemas encontrados (476 casos) — solo detrás de acceso arbitrario a archivos. También documentado en CVE-2025-6514 (CVSS 9.6, crítico) en mcp-remote. Es un análisis estático por patrones de texto (no ejecuta el código) — mismo enfoque que detect_ssrf_risk y detect_path_traversal_risk. Requiere una llave de acceso válida (usos gratis o créditos) — ver POST /crear-llave.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "codigo": "<codigo>"
    },
    "name": "detect_command_injection_risk"
  }
}

Input Schema

Name	Required	Description	Default
`codigo`	Yes	El código fuente de la función/herramienta que ejecuta un comando del sistema, en texto plano.
`lenguaje`	No	Solo informativo (ej. "javascript", "python") — la detección ya cubre varios lenguajes a la vez, este campo no cambia el resultado.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the load and does well: it discloses upfront that this is static analysis that never executes the code, enumerates exactly which patterns are and are not flagged (spawn/execFile without shell:true is explicitly not a risk), and warns that an access key with free uses or credits is required. The main omission is what the result looks like (no output schema either), so the agent cannot anticipate return shape or severity scoring.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the opening clause, but the rest is a single long run-on sentence packing detection rules, false-positive caveats, two CVE references and census statistics. The evidence (9.6% of 4,982 findings, CVSS numbers) is persuasive but not operational, and bullet-style separation of the flagged patterns would have made it far easier to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter static analyzer with no annotations and no output schema, the definition covers scope, detection semantics, non-detections, and auth prerequisites — enough to select and invoke it correctly. Only the return value/severity reporting remains unspecified.

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 coverage is 100%, so both parameters are already documented, and the schema itself states that 'lenguaje' is informational only. The description adds some meaning by illustrating what the input code contains (a filename, a search argument, any parameter), but never explains how to pass the code or that language does not affect results — that is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('analiza el código fuente... en busca de señales de riesgo de inyección de comandos') and scopes it to MCP tools that execute OS commands, which separates it from the other detect_* siblings. An agent can identify the category of finding without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes applicability to source code of a tool that runs an OS command from agent-supplied input, and clarifies the analysis is static pattern matching (no code execution), same approach as detect_ssrf_risk and detect_path_traversal_risk. It does not explicitly say 'use this instead of detect_sql_injection_risk when...', so routing among the other detect_* siblings is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Garita MCP tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?