Skip to main content
Glama
LeandroPG19

Cuba-Memorys

by LeandroPG19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

cuba_receta

Store and retrieve procedural recipes for tasks like starting dev services, running tests, deploying, or migrating, then report outcomes so agents stop rediscovering steps.

Instructions

PROCEDURAL MEMORY: how things are DONE here — bring up the dev services, run the test suite, deploy, migrate. The other tools remember what is TRUE; this one remembers what to DO, so an agent stops rediscovering it every session. Ranked by reliability, not by how often it is read: report the outcome with action='outcome' after running one, or the memory learns nothing. A recipe that keeps failing is worse than none, because it is trusted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoProcedure name, e.g. 'levantar el entorno de desarrollo'
limitNoMax results
queryNoFor action=search
stepsNoOrdered steps: [{do: '...', run: 'comando'?, expect: 'qué debe pasar'?}]
actionYessearch: find by meaning. get: fetch by exact name. add: store/update (re-adding the same name edits it, keeping its track record). outcome: record success/failure — this is what teaches it.
successNoFor action=outcome: did it work?
triggerNoWHEN this applies — the IF half. e.g. 'cuando hay que levantar los servicios de mapupita-web'
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.
verificationNoHow you know it actually worked
preconditionsNoWhat must already be true before starting

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.25.0
    • 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"
+}
  2. First observedv0.18.0

TDQS

A4.3/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 discloses genuinely non-obvious behavior: ranking is by reliability rather than read frequency, and the memory only learns from action='outcome' reporting. The caveat that a persistently failing recipe is worse than none is a real behavioral warning. It does not cover permissions, what delete destroys, or result limits.

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?

The conceptual framing is front-loaded and the actionable 'report the outcome' instruction follows immediately. The concluding aphorism about failing recipes is slightly rhetorical but reinforces the stakes rather than padding, so it mostly earns its place.

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 a 10-parameter tool with no annotations and no output schema, the description adequately explains the mental model and the critical feedback loop, and the schema carries full parameter documentation. Return-shape details for get/search are left implicit, which is a minor gap given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter baseline is 3. The description adds meaning on top by singling out action='outcome' as the teaching mechanism and implying the reliability semantics that the enum alone does not convey, warranting a modest bump.

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?

The description names the resource (procedural memory / recipes for how things are done) and gives concrete examples (bring up dev services, run tests, deploy, migrate). Critically, it distinguishes itself from siblings with 'The other tools remember what is TRUE; this one remembers what to DO,' so an agent can route between the two memory families without reading both schemas.

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

Usage Guidelines4/5

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

It gives explicit operational guidance — report the outcome with action='outcome' after running a recipe or 'the memory learns nothing' — and frames when this tool is the right choice versus the fact-memory siblings. It stops short of saying when NOT to use it (e.g. for exploratory or non-reproducible steps), so it lacks full exclusion coverage.

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