Skip to main content
Glama
Sign In

MemoryBrain

by ai.memorybrain
OverviewDiscussionsAdmin

Apuntar una corrección del usuario

save_correction

Apunta que el usuario te ha corregido: lo que propusiste, lo que dijo para corregirte y la regla que implica. Llámala tú, sin pedir permiso, cada vez que el usuario rechace o cambie lo que le diste porque no era como él lo quiere (no por un error de hecho que ya arreglaste). Entra como deducida: no es una regla suya hasta que la confirme con list_corrections. Si la misma regla ya estaba, cuenta como repetida.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "correction": "<correction>",
      "rule": "<rule>"
    },
    "name": "save_correction"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoQué clase de corrección es.
ruleYesLa regla que implica, en una frase imperativa: «Empieza por el dato, no por el contexto».
skillNoLa skill que estabas siguiendo (get_skill), si había una.
projectNoCon refutes: el proyecto (p1…).
refutesNoLos datos apuntados en ese proyecto que esta corrección desmiente (d1, l2, g3). Quedan refutados.
proposedNoLo que propusiste, resumido (máx. 600).
correctionYesLo que dijo el usuario para corregirte, con sus palabras (máx. 600).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Con refutes: el proyecto (p1…).",
+  "type": "string"
+}
    • addedInput schema / properties / refutes
      Added value: +{
+  "description": "Los datos apuntados en ese proyecto que esta corrección desmiente (d1, l2, g3). Quedan refutados.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-destructive write, so the bar is lower; the description nonetheless adds real behavioral context: entries are created in a provisional 'deducida' state that only becomes a rule after confirmation via list_corrections, and re-saving an existing rule is recorded as 'repetida'. It does not mention the refutes side effect that marks project data as refuted, which is the one materially significant behavior left to the schema.

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 sentences, front-loaded with purpose followed by the call trigger, the provisional-status caveat, and the duplicate rule. Dense but every clause carries information; the long parenthetical in the second sentence slightly hurts scannability.

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

Completeness5/5

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

For a 7-parameter write tool with full schema coverage, no output schema, and annotations present, the description covers purpose, trigger, exclusions, lifecycle state and dedup behavior. The only unaddressed item, the refutes mutation, is fully specified in the schema field itself.

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 every parameter is already documented, including enum values for 'kind' and the refutes semantics. The description only restates in prose what 'proposed', 'correction' and 'rule' capture, without adding format detail or clarifying the skill/project/refutes fields. Baseline 3 applies.

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?

States a specific verb and resource ('Apunta que el usuario te ha corregido') and enumerates the content captured: what you proposed, what the user said, and the implied rule. It is unmistakably distinct from list_corrections (which reads/confirms) and from the save_*/add_* siblings, since the trigger is a user rejection rather than stored content.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('cada vez que el usuario rechace o cambie lo que le diste porque no era como él lo quiere'), an explicit exclusion ('no por un error de hecho que ya arreglaste'), and names the alternative flow ('no es una regla suya hasta que la confirme con list_corrections'). It also settles the autonomy question with 'Llámala tú, sin pedir permiso'.

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

All MemoryBrain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources