hipocampo

save_hipocampo

Store a memory with type, category, and session context for later retrieval. Background processing adds embeddings, deduplicates, and links related memories.

Instructions

Guarda un recuerdo en el Hipocampo (memoria_vectorial).

INSERT inmediato y NO bloqueante: el embedding se genera en background (_finalize_save_bg) junto con dedup semántico, auto-link y auditoría de contradicciones. Hasta que el embedding se backfillea (~segundos), la memoria queda en tier WARM (embedding=NULL) y es recuperable por texto.

Si ya existe un recuerdo casi idéntico (trigram), se advierte y se omite el guardado a menos que force=True. El dedup semántico (>0.9) corre en background y solo loguea — no bloquea.

Args: content: Texto del recuerdo a guardar. memory_type: Tipo de memoria. Valores comunes: "event" (evento/experiencia), "decision" (decisión tomada), "profile" (dato personal). Por defecto: "event". code: Código o etiqueta corta para agrupar recuerdos (opcional). Ej: "documentacion", "bugfix", "feature", "setup". categories: Lista de categorías (opcional). Ej: ["python", "mcp", "infraestructura"]. session_id: Opcional. Identificador de sesión para aislar memorias. force: Si True, guarda incluso si existe un recuerdo muy similar. auto_link: Si True, busca recuerdos semánticamente similares (>0.75) y crea enlaces "similar" automáticamente. nivel: Nivel de memoria jerárquica: "episodica" (default) — detalle completo, comprimible, "semantica" — conocimiento consolidado, protegido, "automatica" — regla permanente, nunca se comprime. critico: Si True, la memoria NUNCA se olvida ni se archiva. Protección de por vida independiente del nivel.

Returns: Confirmación con el ID asignado.

Input Schema

TableJSON Schema

Name	Required	Default
`code`	No
`force`	No
`nivel`	No	episodica
`content`	Yes
`critico`	No
`auto_link`	No
`categories`	No
`session_id`	No
`memory_type`	No	event

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv6.0.0Sep 8, 2026

addedInput schema / properties / critico

Added value: +{
+  "default": false,
+  "title": "Critico",
+  "type": "boolean"
+}

Changed4 schema fields changedv4.3.0Aug 2, 2026

addedInput schema / properties / auto_link

Added value: +{
+  "default": false,
+  "title": "Auto Link",
+  "type": "boolean"
+}

addedInput schema / properties / force

Added value: +{
+  "default": false,
+  "title": "Force",
+  "type": "boolean"
+}

addedInput schema / properties / nivel

Added value: +{
+  "default": "episodica",
+  "title": "Nivel",
+  "type": "string"
+}

addedInput schema / properties / session_id

Added value: +{
+  "default": "",
+  "title": "Session Id",
+  "type": "string"
+}

First observedv1.0.0Jun 18, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it discloses that the insert is non-blocking, the embedding is backfilled in background (_finalize_save_bg), the memory is temporarily WARM with embedding=NULL yet text-recoverable, trigram dedup skips unless force=True, semantic dedup >0.9 only logs, and critico grants lifetime protection. This goes far beyond what the schema or annotations would reveal.

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 layout is clear: one-line purpose, behavior overview, then labeled Args block and a Returns line. Slight redundancy exists — auto-link and dedup appear both in the opening background-task list and again in the parameter notes — but the length is earned given 9 undocumented parameters in the schema.

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

Completeness5/5

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

For a 9-parameter write tool with no annotations and 0% schema description coverage, the description covers purpose, asynchronous behavior, all parameter semantics, dedup edge cases, protection semantics, and the return value (confirmation with assigned ID). The presence of an output schema means return details needn't be spelled out further; little that an agent needs to invoke this correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, and the description fully compensates by documenting all 9 parameters: memory_type with enumerated meanings ('event', 'decision', 'profile'), code/categories with concrete example values, nivel with the three hierarchy levels and their semantics, plus the behavioral meaning of force and auto_link. Every parameter in the schema is explained with meaning beyond its type.

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 the verb and resource explicitly: 'Guarda un recuerdo en el Hipocampo (memoria_vectorial)' — save a memory to the vectorial memory store. The opening also distinguishes the behavior (immediate non-blocking INSERT with background embedding) from any read/update sibling, so an agent can tell save_hipocampo apart from search_hipocampo, update_hipocampo, or link_hipocampo.

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

Usage Guidelines3/5

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

The usage context is strongly implied — this is the primary write path for persisting a new memory — and it explains when a save is skipped (existing near-identical trigram, unless force=True). However, it never names alternatives or states when-not-to-use, e.g., when to update an existing memory via update_hipocampo rather than re-saving, so the agent must infer sibling differentiation.

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