Garita MCP

Escudo de Secuestro de Sampling

detect_sampling_hijack_risk

Analiza el código del lado cliente/host que maneja peticiones de sampling entrantes de un servidor MCP (setRequestHandler sobre CreateMessageRequestSchema / "sampling/createMessage") en busca de: (1) ausencia de cualquier paso reconocible de revisión/aprobación humana antes de cumplir la petición — lo que la propia especificación de MCP recomienda exigir, y la puerta que un servidor malicioso usa para esconder instrucciones que el modelo sigue sin que la persona note nada raro; (2) invocación encubierta de una herramienta (callTool/executeTool) disparada desde ese mismo handler sin aprobación, el vector más grave; y (3) ausencia de un tope de longitud/tokens (maxTokens/max_tokens), el vector de "robo de recursos". Documentado en una investigación de Unit42 (Palo Alto Networks) y reportado de nuevo el 16 de octubre de 2026 contra una app de tipo copiloto de código. Es un análisis estático por patrones de texto (no ejecuta el código) — mismo enfoque que detect_toxic_flow_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_sampling_hijack_risk"
  }
}

Input Schema

Name	Required	Description	Default
`codigo`	Yes	El código del lado cliente/host que maneja peticiones de sampling de un servidor MCP, en texto plano.
`lenguaje`	No	Solo informativo (ej. "javascript", "typescript") — 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?

No annotations are supplied, so the description carries the full burden, and it does substantial work: it discloses that the analysis is static text-pattern matching that does not execute the code, and that access requires a key with free uses or credits. It does not describe the output shape (findings, severity, confidence) or false-positive behavior, which is the remaining gap for an unannotated tool.

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 purpose is front-loaded, which is good, but the single dense paragraph packs long parenthetical asides and cited provenance (Unit42, 16 October 2026 report) that are context rather than instruction. The (1)/(2)/(3) enumeration is genuinely useful structure, but overall the text is longer than the callable information requires.

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 output schema, the definition covers scope, method, vectors checked, and auth prerequisites thoroughly. The one missing piece is what the analysis actually returns, which matters here precisely because no output schema exists to explain the result.

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%, with both parameters documented in the schema itself, including the note that lenguaje does not affect results. The description adds no parameter-level detail beyond restating that the input is the client/host sampling handler code, so the schema is doing the heavy lifting and the 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 (analyze) and a precisely scoped resource (client/host-side code handling incoming MCP sampling requests via setRequestHandler/CreateMessageRequestSchema), then enumerates the three exact vectors it looks for. An agent can distinguish this from siblings like detect_session_hijack_risk or detect_toxic_flow_risk without opening any 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?

The description makes clear the input must be sampling-handler source and references the equivalent approach in detect_toxic_flow_risk, which helps route between the two. It also states the prerequisite (valid access key, see POST /crear-llave). It does not state when NOT to use this tool or what to use for server-side code instead, so it stops short of full alternative routing.

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?