Garita MCP

Escudo de Asignación sin Límite

detect_unbounded_allocation_risk

Analiza el código fuente de un servidor/herramienta en busca de agotamiento de memoria/CPU (CWE-770): (1) lectura completa de un cuerpo de petición o un archivo hacia memoria sin ningún tope de tamaño configurado (sin "limit" en express.json()/bodyParser, sin chequeo de tamaño en la acumulación manual de un stream "req.on('data')", o sin fs.statSync() antes de leer un archivo con ruta no fija); y (2) una reserva de array/buffer (new Array()/Buffer.alloc()), o un bucle, cuyo tamaño/cantidad de vueltas viene directamente de una variable sin ningún tope (Math.min/comparación contra un máximo) antes — un solo mensaje o número grande puede agotar la memoria o la CPU del proceso del agente. El mismo patrón detrás de CVE-2026-14539. Es un análisis estático por patrones de texto (no ejecuta el código ni mide uso real de memoria) — mismo enfoque que detect_dynamic_code_risk y detect_ssrf_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_unbounded_allocation_risk"
  }
}

Input Schema

Name	Required	Description	Default
`codigo`	Yes	El código fuente que lee un cuerpo/archivo o reserva memoria/itera, 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

A3.9/5.0

Behavior4/5

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

No annotations are supplied, yet the description discloses the key behavioral traits: it is a static text-pattern analysis that neither executes the code nor measures real memory, and it requires a valid access key (free uses or credits) via POST /crear-llave. What it omits is the shape of the result (findings, severity, line references), which matters for a detection tool with no output schema.

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 intent is front-loaded in the first clause, but the body is a single very long sentence packed with nested parentheses enumerating sub-patterns, which makes it dense to parse. The content earns its place, but the structure could be broken into distinct sentences without loss.

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

Completeness3/5

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

For a detection tool with no annotations and no output schema, the description covers scope, method, and auth prerequisites well, but says nothing about what comes back (vulnerable/clean verdict, evidence, line numbers) or whether input is a snippet or a whole codebase. That leaves a meaningful gap for an agent planning a call.

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 the two parameters are already documented, and the description's only added nuance (multi-language coverage, lenguaje being purely informational) is already present in the schema text. Baseline 3 applies since the schema carries the semantic load.

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 (analiza) plus the resource (código fuente de un servidor/herramienta) and names the exact vulnerability class (CWE-770) with two enumerated detection patterns. It even distinguishes the approach from siblings by naming detect_dynamic_code_risk and detect_ssrf_risk as the same static-pattern methodology.

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?

It clearly frames applicable input (source code that reads a body/file or allocates memory/loops with untrusted size) so an agent can decide whether a given snippet is in scope. It lacks explicit when-not guidance relative to the other detect_* siblings (e.g. use detect_redos_risk for regex-driven CPU), so it stops short of a 5.

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?