MemoryBrain

Alimentar tu cerebro

feed_brain

Guarda en el cerebro del usuario las notas que TÚ sacas de una fuente que él comparte (artículo, enlace, PDF, vídeo, podcast o texto). Antes de usarla, carga la skill open-brain-extract con get_skill y síguela. Úsala cuando pida guardar, apuntar o alimentar su cerebro con algo. Primero lee la fuente entera; si no puedes abrirla, pídele que pegue el texto. Reglas: una nota = una idea. El título es una frase que afirma la idea (no un tema ni una pregunta). El cuerpo es la voz del autor: parafrasea fiel y cerca de sus palabras, sin opinar ni añadir lo que la fuente no dice, y pon en quote una cita literal cuando la formulación pese. Pon en quote una frase exacta de la fuente en al menos la mitad de las notas (una paráfrasis no cuenta) y 4 a 6 terms por nota. Cada nota se tiene que entender sola dentro de un mes. No saques solo teoría: busca también casos con nombre, técnicas, plantillas, trade-offs y anti-patrones, y márcalos en kind. Entre 3 y 15 notas; si la fuente no tiene nada que merezca guardarse, dilo y no llames a la tool. No escribas lo que opina el usuario: eso lo añade él. Se guarda en el cerebro del usuario, que solo ve él. Conexiones: al final de body, una sección ## Conexiones con una línea por enlace: - Verbo [[destino]] porque …. El servidor tipa cada enlace por el verbo que lo precede: Contradice, Refuta, Refina, Extiende, Depende de, Ejemplifica, Validado por, Aplica a, Alimenta, Refuerza, Operacionaliza; sin verbo, solo «menciona». El destino es el título exacto de otra nota de este lote o el id que dio search_brain para una nota que ya estaba en su cerebro (n12). Conecta solo cuando el verbo sea verdad; no inventes destinos.

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": {
      "source": "<source>",
      "notes": "<notes>"
    },
    "name": "feed_brain"
  }
}

Input Schema

Name	Required	Description
`notes`	Yes
`source`	Yes
`replace`	No	true solo si esta fuente YA estaba guardada y quieres que este lote sustituya al anterior entero. Sin él, un lote que no se parece al anterior entra aparte y no se borra nada.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / replace

Added value: +{
+  "description": "true solo si esta fuente YA estaba guardada y quieres que este lote sustituya al anterior entero. Sin él, un lote que no se parece al anterior entra aparte y no se borra nada.",
+  "type": "boolean"
+}

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only mark this as a non-read-only, non-idempotent write; the description goes much further by disclosing privacy ("se guarda en el cerebro del usuario, que solo ve él"), accumulation semantics (a dissimilar batch "entra aparte y no se borra nada"), and that repeating a `part` number replaces that batch. It also warns not to invent link destinations, which is a real behavioral failure mode. The replace/part overwrite behavior is disclosed in prose, so there is no contradiction with the annotations, though it is worth noting that opt-in replacement of a prior batch sits in tension with destructiveHint=false.

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?

Nearly every sentence carries real information, but it is delivered as one undifferentiated block with no headings or bullets, mixing purpose, skill prerequisite, content-quality rules, and link syntax. There is also mild redundancy between "sin opinar ni añadir lo que la fuente no dice" and "No escribas lo que opina el usuario". Front-loading is good (purpose and prerequisite come first), but scanability suffers.

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 complex nested-payload write tool with no output schema and thin schema coverage, the description covers the hard parts: extraction workflow, note count bounds (3-15), self-containment requirement, linking rules, and replacement semantics. The main gap is that it never says what the tool returns (ids, confirmation, counts), which matters because the agent is expected to later reference these notes.

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

Parameters5/5

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

Schema coverage is only 33%, but the description compensates heavily: it constrains `title` to an affirmative sentence (not a topic or question), requires literal `quote` in at least half the notes, mandates 4-6 `terms`, tells the agent to mark non-theory items in `kind`, and specifies the `## Conexiones` line format. Most importantly it enumerates the eleven linking verbs that the server uses to type each connection (Contradice, Refuta, Refina, Extiende, Depende de, Ejemplifica, Validado por, Aplica a, Alimenta, Refuerza, Operacionaliza) plus the default «menciona» — information found nowhere in the schema.

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: "Guarda en el cerebro del usuario las notas que TÚ sacas de una fuente", and enumerates the source types (artículo, enlace, PDF, vídeo, podcast, texto). It is distinguishable from siblings by naming get_skill as a prerequisite and search_brain as the source of existing note ids, so an agent knows this is the write path rather than a search path.

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 explicit triggers ("Úsala cuando pida guardar, apuntar o alimentar su cerebro"), an explicit exclusion ("si la fuente no tiene nada que merezca guardarse, dilo y no llames a la tool"), and a fallback path ("si no puedes abrirla, pídele que pegue el texto"). It also names the mandatory prerequisite skill (open-brain-extract via get_skill), which is the kind of routing detail most definitions omit.

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.