Skip to main content
Glama
LeandroPG19

Cuba-Memorys

by LeandroPG19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

cuba_proyecto

Manage project-scoped memories to prevent cross-project bleed. Actions: list, switch, stats, rename, merge, backfill.

Instructions

Project scoping (v0.8): isolate memories per project so multiple projects sharing one DB don't bleed into each other. Active project is bound to the current session (cuba_jornada start --project NAME). Legacy NULL project_id rows are hidden while a project is active unless faro include_unscoped=true or you backfill them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoDestination name (for rename/merge)
nameNoProject name (for switch/stats/rename source/backfill)
actionYesProject action. backfill assigns every NULL project_id row to `name` (dry-run unless confirm=true).
confirmNobackfill only: write the assignment. Default false (dry-run).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.27.0
    • changedInput schema / properties / action / description
      Previous value: -"Project action"New value: +"Project action. backfill assigns every NULL project_id row to `name` (dry-run unless confirm=true)."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "list",
-  "current",
-  "switch",
-  "stats",
-  "rename",
-  "merge"
-]New value: +[
+  "list",
+  "current",
+  "switch",
+  "stats",
+  "rename",
+  "merge",
+  "backfill"
+]
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "backfill only: write the assignment. Default false (dry-run).",
+  "type": "boolean"
+}
    • changedInput schema / properties / name / description
      Previous value: -"Project name (for switch/stats/rename source)"New value: +"Project name (for switch/stats/rename source/backfill)"
  2. First observedv0.18.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the visibility rule that legacy NULL project_id rows are hidden while a project is active unless faro include_unscoped=true or a backfill is run – genuinely valuable state behavior. It omits, however, the side effects and reversibility of the mutating actions (rename, merge, backfill), any permission requirements, and what switching projects does to the current session.

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?

Two dense sentences with the core concept front-loaded and the visibility caveat appended efficiently. It is jargon-heavy (v0.8, cuba_jornada, faro include_unscoped) but every sentence carries information and there is no padding.

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 seven-action tool with no annotations and no output schema, the description covers the conceptual model and one important visibility caveat, but it does not describe the semantics or effects of the individual actions (switch, rename, merge, stats) beyond what the schema enum already encodes, leaving an agent to infer operational behavior.

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%, so the schema already documents all four parameters including the backfill/confirm semantics. The description adds the session-binding context but otherwise does not extend parameter meaning beyond what the schema provides, making the baseline 3 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?

The description clearly conveys the resource and intent – project scoping that isolates memories per project – and explains the mechanism (active project bound to session via cuba_jornada start --project NAME). However, it does not explicitly state that this tool exposes the project management operations (list/current/switch/rename/merge/backfill), which the agent only learns from the schema enum, and it does not differentiate itself from the sibling memory_proyecto.

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?

The description implies the context in which project scoping matters (multiple projects sharing one DB) and explains how the active project is established, but it never states when to call this tool versus alternatives like cuba_jornada or memory_proyecto, nor which action to reach for under what circumstance.

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