Skip to main content
Glama

memory_cronica

Attach facts, lessons, decisions, and episodic events to entities, view chronological timelines, and auto-create missing entities while blocking near-duplicates in AI coding agent memory.

Instructions

[alias of cuba_cronica] Attach facts/lessons/decisions to entities. Also manages episodic memories (specific events with actors/artifacts) via episode_add/episode_list. Timeline view shows chronological history. Auto-creates entity if not found. Dedup gate blocks near-duplicates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesOperation to perform. episode_add stores a temporal event; episode_list retrieves events. timeline shows chronological observations+episodes.
actorsNoPeople/agents involved in episode (for episode_add)
sourceNoWho/what created this observation
contentNoObservation or episode text
artifactsNoFiles/resources affected in episode (for episode_add)
entity_nameNoEntity to attach observation/episode to
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.
observationsNoArray of {entity_name, content, observation_type?, source?} objects (for batch_add, max 100)
observation_idNoObservation UUID (for delete action)
observation_typeNoType of observation

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations at all, the description carries the full burden but does add real behavioral context: auto-creation of missing entities, a dedup gate blocking near-duplicates, and the differentiation of episode vs timeline storage. It says nothing about destructive delete semantics, batch limits, or the credential-refusal/allow_secret exposure behavior that matter for a mutating multi-action tool.

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?

Four tight sentences, front-loaded with the alias and the core operation, then the episodic/timeline additions and two behavioral caveats. No filler, though the alias-first framing arguably wastes the opening clause.

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 7-action tool with 10 parameters, no annotations, and no output schema, the description sketches the shape but leaves delete, list, and batch_add behavior unspecified and gives no return-value or pagination context. Adequate as a minimum-viable overview, not complete.

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 coverage is 100%, so the schema already documents all 10 parameters including enum values for action, source, and observation_type. The description adds only loose mapping of episode_add/episode_list/timeline to the action enum, which the schema itself restates — baseline 3 is appropriate.

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?

Names a concrete verb+resource ('Attach facts/lessons/decisions to entities') and enumerates the additional functions (episodic memories, timeline view). The alias note points to cuba_cronica, which is a sibling, but nothing states how this differs functionally from memory_remedio, memory_expediente, or cuba_cronica beyond the alias equivalence.

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?

Usage is implied rather than directed: the description explains that episode_add/episode_list handle events and timeline gives chronological history, so an agent can infer when to pick each action. It never says when to prefer this tool over the many memory_*/cuba_* siblings, nor any prerequisites.

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