Skip to main content
Glama
LeandroPG19

Cuba-Memorys

by LeandroPG19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

cuba_eco

Give RLHF feedback to boost or correct memories, and promote or quarantine withheld observations, episodes, and errors to control retrievability.

Instructions

RLHF feedback: positive boosts importance (Oja's rule), negative decreases, correct updates content. Also the quarantine gate: 'pending' lists memories withheld from search because they came from untrusted text, 'promote' makes one retrievable, 'quarantine' withdraws one. The gate covers observations, episodes and errors — pick which with 'kind'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoTarget UUID for promote/quarantine when kind is episode or error. For kind=observation use observation_id.
kindNoWhich table promote/quarantine acts on. Default 'observation'. An import quarantines whatever carried a credential, and cuba_sync writes episodes and errors too: without the matching kind those rows would stay stored and permanently unreachable. Ignored by positive/negative/correct, and by pending, which always returns all three.
limitNoMax rows for the 'pending' listing (default 20, max 200)
actionYesFeedback type, or a quarantine transition: promote/quarantine flip one memory's retrievability; pending lists everything currently withheld, in three lists (quarantined, quarantined_episodes, quarantined_errors), each row tagged with its kind.
correctionNoNew content (for correct action)
entity_nameNoTarget entity
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.
observation_idNoTarget observation UUID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.25.0
    • changedInput schema / properties / action / description
      Previous value: -"Feedback type, or a quarantine transition: promote/quarantine flip one observation's retrievability; pending lists what is currently withheld."New value: +"Feedback type, or a quarantine transition: promote/quarantine flip one memory's retrievability; pending lists everything currently withheld, in three lists (quarantined, quarantined_episodes, quarantined_errors), each row tagged with its kind."
    • addedInput schema / properties / allow_secret
      Added value: +{
+  "description": "Refused 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.",
+  "type": "boolean"
+}
    • addedInput schema / properties / id
      Added value: +{
+  "description": "Target UUID for promote/quarantine when kind is episode or error. For kind=observation use observation_id.",
+  "type": "string"
+}
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "Which table promote/quarantine acts on. Default 'observation'. An import quarantines whatever carried a credential, and cuba_sync writes episodes and errors too: without the matching kind those rows would stay stored and permanently unreachable. Ignored by positive/negative/correct, and by pending, which always returns all three.",
+  "enum": [
+    "observation",
+    "episode",
+    "error"
+  ],
+  "type": "string"
+}
  2. First observedv0.18.0

TDQS

B3.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explains that positive/negative use Oja's rule to boost or decrease importance, that correct overwrites content, that 'pending' lists withheld memories from untrusted text, and that promote/quarantine flip retrievability. It also notes the gate covers observations, episodes and errors. What is missing is the reversibility of promote/quarantine, whether feedback is idempotent, and any error conditions. Strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single long block that mixes two unrelated functional areas (RLHF feedback and quarantine transitions) without headings or bullets, and it front-loads the RLHF part before the gate. It is not padded, but the structure makes it hard to scan and the opening sentence assumes the reader already knows what 'cuba_eco' is.

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

Completeness4/5

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

For an 8-parameter tool with no annotations and no output schema, the description covers the main behaviors: how feedback changes importance, how corrections replace content, and how the quarantine gate filters, promotes and quarantines across three kinds. It does not describe the pending return format in detail beyond naming the three lists, and it does not state what the tool returns for other actions, but the schema elsewhere is fully documented and this is close to sufficient.

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 every parameter including the enum semantics and the kind selection. The description adds context that 'kind' exists to target observations, episodes or errors and that pending ignores it, but this largely repeats what the schema descriptions already state. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose3/5

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

The description names two distinct capabilities (RLHF feedback and a quarantine gate) with specific actions, but the tool name 'cuba_eco' provides no hint and the description begins mid-thought. It is possible to reconstruct the tool's purpose from the text plus the action enum, but the description itself is vague about the overall scope (is this one tool or two merged together?) and does not distinguish it from siblings like memory_eco or cuba_centinela.

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?

There is no explicit when-to-use guidance. The description explains what each action does but never states when to choose positive vs correct, or when to use pending before promote. The sibling list is long and no alternative tool is named for any scenario. Usage is implied only by action semantics.

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