Saltar al contenido principal

Referencia API

iLAB Memory ofrece una sola fachada — ILabMemory — y tres transports que se mapean 1:1 contra ella. Elegí el transport según tu runtime; la semántica es idéntica en todos.

Cuándo usar cada una

SurfaceUsá cuando…Evitá si…
LibreríaSos dueño del proceso Python. Querés cero overhead de IPC y objetos directos (Observation, SessionStartResponse).Múltiples procesos o consumidores no-Python necesitan compartir la misma memoria.
HTTP RESTOtro servicio (Node, Go, navegador) lee/escribe memoria. Querés tooling OpenAPI, rate limits y CORS de fábrica.Un único script Python es el único consumidor (usá la librería y ahorrate el salto de red).
MCP stdioUn IDE o host de agente (Claude Code, Claude Desktop, Cursor) necesita llamar memoria como tools. Las 8 tools vienen pre-descritas — sin glue code.Necesitás acceso REST ad-hoc desde clientes arbitrarios (usá HTTP).
nota

Las tres surfaces serializan los mismos modelos Pydantic de ilab_memory.core.models. Esto es Braess #6 — el wire format es single-source-of-truth. Un SaveResult por HTTP, MCP o Python in-process tiene exactamente los mismos campos y reglas de validación.

Qué hay en esta sección

  • Librería — referencia completa de la clase ILabMemory: constructor, factory from_path y los 8 métodos de la fachada (mem_session_start, mem_save, mem_search, …).
  • HTTP API — el spec OpenAPI completo está disponible en /docs/openapi.json. Cargalo en Swagger UI, Redoc o Postman para explorar interactivamente. La sección de la librería de arriba documenta los mismos modelos Pydantic que el HTTP serializa.
  • MCP Server — snippets de setup para Claude Code, Claude Desktop y Cursor. Los docstrings de las tools viajan con el server, así que el agente no necesita un CLAUDE.md externo para usarlas correctamente.