Garita MCP

Escudo de Esquema de Salida

detect_output_schema_ssrf_risk

Analiza el código del lado CLIENTE que valida el outputSchema/inputSchema de una herramienta MCP en busca de: (1) una validación con la librería jsonschema (Draft*Validator/validator_for/jsonschema.validate) sobre un esquema que vino de un servidor MCP no confiable, sin ningún Registry/Resolver que restrinja la resolución de referencias externas ($ref/$dynamicRef/$id) — un servidor malicioso puede forzar al cliente a hacer una petición SSRF hacia una URL arbitraria (CWE-918); y (2) una llamada de red SÍNCRONA (urllib.request.urlopen/requests.get-post-put-delete) dentro de una función "async def", sin "timeout" ni delegarse a un hilo aparte — un solo endpoint que nunca responde congela el event loop entero del proceso (denegación de servicio). El mismo patrón detrás de CVE-2026-116686 (CVSS 6.5) en el SDK oficial de Python de MCP (paquete "mcp" en PyPI, versiones 1.10.0-1.29.1 y 2.0.0-2.1.1; parchado en 1.30.0/2.2.0). Es un análisis estático por patrones de texto (no ejecuta el código) — mismo enfoque que detect_ssrf_risk y detect_redos_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_output_schema_ssrf_risk"
  }
}

Input Schema

Name	Required	Description	Default
`codigo`	Yes	El código del lado cliente que valida outputSchema/inputSchema de herramientas MCP, en texto plano.
`lenguaje`	No	Solo informativo (ej. "python") — este campo no cambia el resultado.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations at all, the description carries the full behavioral burden, and it does disclose meaningful traits: static text-pattern analysis with no code execution, the auth requirement, the exact CVE/package/version range context, and the impact framing (SSRF, event-loop DoS). However, it says nothing about what the tool returns (no output schema exists), whether results are scored/findings-per-issue, or how it behaves on unparseable input — a notable gap for a zero-annotation tool.

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 two checks are front-loaded as numbered items (1) and (2), so the agent gets the core purpose immediately despite the dense parenthetical nesting of library names and CVE identifiers. The content is substantive rather than padded, though the single long block would be easier to scan if the CVE/citation material were separated.

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?

The detection criteria, static-analysis limitation, and authentication requirement are all well covered for a moderately complex tool. Missing is any statement of the response shape or finding structure — with no output schema and no annotations, that is the one thing an agent still cannot infer before calling.

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% for both parameters, so the baseline is 3. The description adds that the input is client-side source code for MCP schema validation in plain text, but it adds no meaning about the two parameters beyond the schema — notably it does not mention that 'lenguaje' is informational only, which the schema itself already states.

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?

The description names a precise verb and resource: it analyzes CLIENT-SIDE code that validates outputSchema/inputSchema of an MCP tool. It enumerates the two exact defect patterns it looks for (jsonschema Draft*Validator on an untrusted server schema without a Registry/Resolver enabling $ref SSRF; synchronous network calls inside an async def without timeout), which makes it unmistakably distinct from the generic siblings detect_ssrf_risk and detect_redos_risk.

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 scopes the tool to client-side MCP schema-validation code and states the operational prerequisites (valid access key, free uses or credits, see POST /crear-llave). It also notes the analysis mirrors detect_ssrf_risk and detect_redos_risk, but it never explicitly routes the agent ('use this instead of X when...'), so the when-not guidance remains 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?