MemoryBrain

Guardar un output

save_output

Guarda o actualiza un documento vivo del proyecto: propuesta de valor, flujo, visión, pitch, diseño o runbook. Al actualizar, la versión anterior se guarda.

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": {
      "project": "<project>"
    },
    "name": "save_output"
  }
}

Input Schema

Name	Required	Description
`id`	No	Para actualizar uno (o1).
`url`	No	Dónde vive, si está fuera.
`kind`	No
`note`	No	Una nota de su cerebro que lo contiene.
`uses`	No	Lo que este output usa de verdad: decisiones, aprendizajes y trampas del proyecto (d1, l2, g3) y notas de su cerebro que has aplicado (n4). Quedan como usados.
`title`	No
`content`	No	El texto entero.
`project`	Yes	El proyecto (p1, p2…), de list_projects.
`delivered`	No	true solo si el usuario dice que lo ha enviado, publicado o dado por bueno. Lo que usó y nadie ha corregido pasa a verificado por uso.
`occurred_on`	No	Cuándo pasó, AAAA-MM-DD, solo si lo dice él o la fuente. Si cuenta algo de hoy sin dar fecha, déjalo vacío: no pongas hoy.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / uses / description

Previous value: -"Las decisiones, aprendizajes y trampas del proyecto que este output usa de verdad (d1, l2, g3). Quedan como usados."New value: +"Lo que este output usa de verdad: decisiones, aprendizajes y trampas del proyecto (d1, l2, g3) y notas de su cerebro que has aplicado (n4). Quedan como usados."

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / delivered

Added value: +{
+  "description": "true solo si el usuario dice que lo ha enviado, publicado o dado por bueno. Lo que usó y nadie ha corregido pasa a verificado por uso.",
+  "type": "boolean"
+}

addedInput schema / properties / uses

Added value: +{
+  "description": "Las decisiones, aprendizajes y trampas del proyecto que este output usa de verdad (d1, l2, g3). Quedan como usados.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

AddedNov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already state this is a non-readonly, non-destructive, non-idempotent write. The description adds real value beyond them: it discloses versioning behavior ('la versión anterior se guarda'), which tells the agent that updating does not lose prior content. It does not cover auth, limits, or return shape, but the versioning note is the key missing piece annotations cannot express.

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

Conciseness5/5

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

Two short sentences, front-loaded with the core action and followed by the one non-obvious behavioral fact. No filler or redundant restatement of the name.

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 mutation tool with no output schema, the description plus rich schema descriptions cover what an agent needs to call it. The main residual gap is the absence of routing guidance toward sibling save_* tools, which matters given how many similar names exist.

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 80%, so the schema already carries most parameter meaning, including the update-via-id hint and the strict delivered/occurred_on rules. The description only alludes to updating and adds no syntax or semantics beyond the schema, which is the expected baseline at this coverage level.

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 names a specific verb pair (guarda o actualiza) and resource (documento vivo del proyecto), then enumerates the concrete document kinds it covers. It distinguishes create from update implicitly via 'Al actualizar', but never contrasts itself with nearby save_* siblings.

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 by the enumeration of living-document types, so an agent can infer this is for project artifacts rather than arbitrary notes. There is no explicit when-not guidance and no mention of alternatives such as save_context or save_format for other kinds of content.

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

All MemoryBrain tools Inspect

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.