Skip to main content
Glama
LeandroPG19

Cuba-Memorys

by LeandroPG19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

memory_zafra

Keep AI coding agent memory accurate: decay, prune, merge, summarize, rank, deduplicate, export, and re-embed project-scoped observations.

Instructions

[alias of cuba_zafra] Memory maintenance, scoped to the active project: decay, prune, merge, summarize, pagerank, find_duplicates, export, reembed, decay_episodes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cNoPower-law c parameter for decay_episodes (default 0.1)
betaNoPower-law β exponent for decay_episodes (default 0.5)
actionYesdecay: stratified exponential decay by type. prune: deletes low-importance observations, dry-run unless confirm=true. merge: deduplicates similar entities. summarize: replaces an entity's observations with compressed_summary. stats: counts. pagerank: personalized importance ranking. find_duplicates: lists near-duplicate pairs. export: writes a JSON dump. reembed: re-encodes with the current model. decay_episodes: power-law decay on brain_episodes.
confirmNoprune only: actually delete. Without it, prune returns a dry-run plan (would_prune, by_project) and deletes nothing — read the plan first, the default threshold reaches a large share of a mature corpus.
thresholdNoImportance threshold for prune (default 0.1)
batch_sizeNoMax observations to re-encode in reembed (default 500)
entity_nameNoEntity to summarize (for summarize action)
allow_secretNoRefused when the text looks like a live credential (token, password, URL with embedded creds). Set true only for a false match — the text is then stored verbatim, in clear, and reachable by search, export and every client.
halflife_daysNoGlobal halflife override for decay (overrides per-type stratification)
compressed_summaryNoCompressed text replacing observations (for summarize)
similarity_thresholdNoSimilarity threshold for merge (default 0.8)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden, yet it discloses only the active-project scoping. Destructive actions bundled into the same tool (prune deletes observations, summarize replaces observations, merge deduplicates) are not flagged in the description; the safety details live only in the schema's per-parameter prose.

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?

One sentence, front-loaded with the alias relationship followed by the action list, with no filler. The alias tag consumes the opening slot that could have carried usage guidance, but the sentence itself is economical.

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 an 11-parameter, multi-action tool with no output schema and no annotations, the description is thin: it gives the action roster but no ordering, destructive-action warnings, or selection logic. The unusually rich schema compensates for most parameter gaps, keeping this at minimum-viable rather than inadequate.

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% and the action enum is thoroughly documented in the schema, so the tool meets the baseline where structured data already does the heavy lifting. The description adds no format, default, or interaction details beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (memory), the scope (active project) and enumerates the concrete maintenance actions, so an agent knows this is a memory-upkeep tool rather than an ingest or query tool. It does not, however, explicitly differentiate itself from its sibling cuba_zafra beyond the '[alias of]' tag.

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

Usage Guidelines2/5

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

It lists the available actions but gives no guidance on when to choose this tool over its alias cuba_zafra or over the many sibling memory_* tools, nor on which action suits which situation. 'Scoped to the active project' is the only selection hint and it is implicit at best.

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

Deploy Server

Other Tools