Garita MCP

Escudo de Lanzamiento MCP (STDIO)

detect_mcp_stdio_launch_risk

Analiza el código que arma la conexión de un CLIENTE MCP por transporte "stdio" (StdioClientTransport del SDK de TypeScript, StdioServerParameters del SDK de Python) en busca de una falla de DISEÑO confirmada en los cuatro SDKs oficiales de MCP (Python, TypeScript, Java, Rust) en 2026: el sistema operativo ejecuta el campo "command" de inmediato al construir/conectar el transporte, ANTES de que exista ninguna validación del protocolo MCP — "incluso cuando el comando malicioso falla en establecer una sesión MCP válida... el comando ya se ejecutó" (Cloud Security Alliance). Si "command"/"args" viene de una entrada externa sin restringirlo a una lista de lanzadores conocidos, cualquiera que controle ese campo ejecuta código arbitrario. Detecta: (1) "command" dependiente de una entrada externa sin ninguna validación reconocible contra una lista de lanzadores permitidos; (2) una variante más sutil ("brecha de rehidratación"): el archivo sí valida en algún lado, pero el lanzamiento analizado viene de una configuración ya guardada/ cargada antes, sin volver a validar al momento de lanzarla de verdad — el patrón exacto detrás de CVE-2026-30623 (LiteLLM) antes de su parche; (3) un comando SÍ presente en una lista blanca razonable (python, node, etc.) cuyos argumentos incluyen una bandera de ejecución directa de código (-c/-e/--eval) con un valor que no es fijo — la lista blanca por nombre de binario no alcanza si el atacante solo elige el código que ese binario ya permitido va a ejecutar; y (4) la falsa sensación de seguridad de asumir que si el comando no resulta un servidor MCP válido "el protocolo fallaría" y ahí termina el problema. También documentado en CVE-2026-22688 (Tencent WeKnora, CVSS 9.9): mismo patrón, expuesto en un endpoint "/test" sin control de acceso de administrador. Distinto y complementario a detect_command_injection_risk: ese cubre la inyección de comandos clásica vía una shell del sistema; este cubre el contrato específico de los SDKs de MCP, donde el riesgo existe aunque no haya ninguna shell de por medio. Es un análisis estático por patrones de texto (no ejecuta el código) — mismo enfoque que detect_command_injection_risk y detect_missing_auth_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_mcp_stdio_launch_risk"
  }
}

Input Schema

Name	Required	Description	Default
`codigo`	Yes	El código que arma la conexión stdio de un cliente MCP (construcción de StdioClientTransport/StdioServerParameters), en texto plano.
`lenguaje`	No	Solo informativo (ej. "javascript", "python") — la detección ya cubre varios SDKs 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 supplied, the description carries the load well: it discloses that nothing is executed (static pattern matching, same approach as sibling detectors), that a valid access key or credits are needed with a pointer to POST /crear-llave, and it explains the underlying mechanism (command runs at transport construction before any MCP validation). It does not describe the shape or severity of the findings returned.

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?

The opening sentence correctly front-loads what is analyzed, but the body is one dense run-on paragraph packing four detection cases, two CVEs with versions and CVSS scores, and authentication notes. The CVE-2026-22688 / '/test' endpoint detail is illustrative but the least load-bearing part for an agent choosing and calling the tool.

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 scanner with no annotations and no output schema, the description covers input preconditions, auth requirements, analysis mode, and detection scope thoroughly. The notable remaining gap is the absence of any statement about what the analysis returns (findings list, severity, confidence), which an agent would otherwise need the output schema for.

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 — including that 'lenguaje' is informational only. The description reinforces the scope of 'codigo' (the code that builds the stdio connection) but adds no format, size, or minimal-reproduction guidance beyond the schema. Baseline 3 applies.

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: static analysis of MCP client stdio connection code (StdioClientTransport / StdioServerParameters) for a design flaw. It enumerates four concrete detection categories and explicitly contrasts itself with the sibling detect_command_injection_risk, so an agent can distinguish it without opening either 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?

Gives a clear boundary rule against the closest sibling: command injection via a system shell belongs to detect_command_injection_risk, while the MCP SDK launch contract (risk present even without a shell) belongs here. It also states the analysis is static/pattern-based and that an access key is required, but does not spell out when NOT to run it (e.g., non-stdio transports or server-side code).

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?