Skip to main content
Glama

Detectar envenenamiento de memoria persistente

detect_memory_poisoning

Revisa un texto que un agente con memoria de largo plazo va a guardar (o que ya guardó) en busca de instrucciones plantadas para activarse recién en una sesión futura, sin relación con la conversación donde se coló el texto. Distinto de detect_poisoned_tool_descriptions (Garita Escudo): ese revisa la descripción de una HERRAMIENTA; este revisa CONTENIDO que va hacia la memoria — una nota, un hecho guardado, un resumen automático de una conversación vieja, o texto traído por otra herramienta (documento, página web, salida de una API). Detecta: instrucciones condicionales tipo "si el usuario dice que sí, entonces..." (el método documentado del ataque real contra Gemini, investigador Rehberger 2025, y el método MINJA de NeurIPS 2025 con más de 95% de éxito contra agentes en producción), la combinación de "recordá esto para siempre" + "no se lo menciones al usuario" (casi nunca legítima venga de donde venga), texto que se hace pasar por una instrucción del sistema o pide ignorar instrucciones anteriores, instrucciones de enviar datos a un tercero la próxima vez que se recupere la memoria, etiquetas falsas de sistema escondidas en el contenido, y texto que se dirige directamente al asistente por su nombre dentro de contenido que debería ser pasivo (un documento, una página web). El campo "fuente" importa: un usuario pidiéndole directamente al agente que recuerde algo es el uso normal del producto y se pondera distinto a lo mismo encontrado dentro de un documento, un resumen automático o la salida de otra herramienta. 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": {
      "texto": "<texto>"
    },
    "name": "detect_memory_poisoning"
  }
}

Input Schema

NameRequiredDescriptionDefault
textoYesEl contenido que se va a guardar (o que ya está guardado) en la memoria de largo plazo del agente.
fuenteNoDe dónde viene el texto: usuario_directo, documento_o_web, resumen_automatico, salida_de_herramienta, desconocida. Si no se especifica, se trata como no confiable por precaución.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/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 burden, and it does substantial work: it enumerates the attack patterns detected, notes that source provenance changes weighting, and discloses an auth requirement (valid access key, free uses or credits, POST /crear-llave). Missing is any disclosure of what the tool returns (verdict, risk level, matched category) and whether there are input-size or rate limits.

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 first sentence, but the body is one dense run-on paragraph that stacks enumerations, parenthetical citations to attack research (Reuberger 2025, MINJA, 95% success rates), and an auth note wedged into the middle. The research citations do not help an agent decide whether or how to call the tool and could be cut.

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 two-parameter scanner with no output schema, the description covers input semantics, detection scope, provenance weighting, and auth well, but says nothing about the shape of the response an agent must act on (clean versus flagged, severity, rationale). That gap matters most here because there is no output schema to carry it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that 'fuente' materially changes how aggressively the text is judged, with user_directo treated as normal product usage versus document/web/auto-summary output. The 'texto' parameter's role is also clarified as memory-bound content rather than arbitrary input.

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 first sentence states a specific verb and resource: reviewing text an agent with long-term memory is about to save (or already saved) for planted instructions that activate in a future session. It also names the sibling it is not (detect_poisoned_tool_descriptions, which reviews tool descriptions rather than memory-bound content), so an agent can route between them without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use (content heading into memory: a note, a stored fact, an auto-summary of an old conversation, or text pulled from another tool) and an explicit alternative with the condition that selects it. It further guides judgment by saying the 'fuente' field changes weighting: a direct user request is normal product usage, the same claim inside a document or auto-summary is not.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources