Skip to main content
Glama

Save memory

mem_save
Destructive

Guarda una memoria del agente en un scope (proyecto/repo). scope es el nombre del proyecto (el de la carpeta del repo, igual que tu identificador de proyecto): el scope se auto-registra la primera vez. type categoriza la observación. topic_key agrupa memorias del mismo tema (opcional). Opcionalmente scope_name/root_path enriquecen el registro del scope, y git_remote (la URL de git remote get-url origin) lo IDENTIFICA: si ya hay un scope de ese repo, la memoria va a ese aunque tu carpeta se llame distinto, y si tu carpeta tenía scope propio sin repo se fusiona en él. Conviene pasarlo cuando el repo tiene remote; si el repo tiene un fichero .hilbana/scope, su contenido es el scope y no se pasa git_remote. session_id/metadata anotan la memoria. replaces (opcional) es el id de una memoria de ESTE scope que la nueva deja obsoleta: se borra en el mismo paso. Úsalo cuando corrijas o actualices algo que ya estaba guardado, en vez de dejar dos versiones que se contradicen. El scope lo comparte el equipo: NO guardes lo que solo vale en tu máquina (rutas absolutas, puertos locales, nombres de máquina, tu configuración personal); a otra persona le confunde, y la ruta en la que trabajas ya la sabes. Cada memoria queda firmada con el usuario de tu credencial. Si tu credencial está acotada a un proyecto, el scope que crees queda DENTRO de ese proyecto y solo lo recupera quien tenga acceso a él. SE GUARDA EN EL WORKSPACE QUE ESTÁS TRABAJANDO: si tienes una issue reclamada (claim_issue), la memoria va a SU workspace para que le sirva a ese equipo; si no, al workspace por defecto. La respuesta dice en cuál quedó. Pasa workspaceId para forzarlo — y piénsalo antes de guardar algo personal (cómo trabajas tú) mientras trabajas para otro workspace: acaba siendo visible para su equipo.

Input Schema

NameRequiredDescriptionDefault
typeYes
scopeYes
contentYes
metadataNo
replacesNo
root_pathNo
topic_keyNo
git_remoteNo
scope_nameNo
session_idNo
workspaceIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: scopes auto-register, `git_remote` can identify and merge scopes, `replaces` deletes the old memory in the same step, credentials constrain scope visibility, and memories land in the claimed issue workspace by default. This meaningfully explains destructive and workspace-affecting behavior.

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?

Purpose and scope are front-loaded, and most sentences add necessary semantics or warnings. It is dense and occasionally run-on, especially around workspace targeting and credential scoping, but the length is justified by the 11-parameter surface and subtle behavior.

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?

Complete enough for an agent to call correctly even without an output schema: it explains default workspace behavior, response disclosure, scope identity, replacement behavior, and safety constraints. No major decision-relevant behavior is omitted.

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?

With 0% schema description coverage and 11 parameters, the description carries the burden well: it explains `scope`, `type`, `topic_key`, `scope_name`, `root_path`, `git_remote`, `session_id`, `metadata`, `replaces`, and `workspaceId`, including subtle merge and override semantics. Only the enum meanings for `type` and `content` formatting are lightly covered, but the key semantics are present.

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 and resource: save an agent memory in a project/repo scope. It distinguishes the tool from retrieval siblings like mem_search and mem_get by describing persistence, scope registration, and replacement behavior.

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?

Gives explicit conditions: use `replaces` when correcting obsolete saved memories, pass `git_remote` when the repo has a remote, do not pass it when `.hilbana/scope` exists, and set `workspaceId` only to force a workspace. It also warns against saving machine-specific personal data to a shared team scope.

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