MemoryBrain

Pasarle esta conversación a Carlos

send_handoff

Prepara y envía a Carlos (quien creó MemoryBrain) un handoff de ESTA conversación, para que la analice. Úsala cuando el usuario diga que quiere pasarle, mandarle o compartir con Carlos lo que habéis hablado, un fallo, una duda o un resultado, o cuando Carlos le haya pedido que se lo pase. Carga antes la skill handoff con get_skill y síguela. Son DOS pasos y no te puedes saltar el primero: llama sin confirmed, enséñale al usuario el borrador ENTERO tal cual lo devuelve la tool y pregúntale si lo manda; solo con su sí, repite la llamada con los mismos campos y confirmed: true. Si pide cambiar algo, cámbialo y vuelve al primer paso. summary es lo que ha pasado, en tus palabras, en pocas líneas. transcript es la conversación en Markdown (Usuario / IA), lo más fiel que puedas, sin inventar ni resumir dentro de ella; si es muy larga, manda lo que importa y dilo en note. No metas claves, contraseñas ni datos de terceros que no hagan falta. No guarda nada en el cerebro del usuario.

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": {
      "title": "<title>",
      "summary": "<summary>"
    },
    "name": "send_handoff"
  }
}

Input Schema

Name	Required	Description
`ask`	No	Qué quiere el usuario que Carlos mire o decida, si lo dice (máx. 1.000).
`note`	No	Algo que el usuario quiere añadir, o qué has dejado fuera del transcript (máx. 1.000).
`title`	Yes	Qué es, en una línea (máx. 120).
`client`	No	Desde dónde habla: ChatGPT, Claude, Cursor… Si lo sabes.
`summary`	Yes	Qué ha pasado y en qué punto está, en pocas líneas (máx. 4.000).
`brain_use`	No	Cuántas notas del brain has usado y qué aportas tú que no está en ninguna. Si es cero, di cero (máx. 1.000).
`confirmed`	No	true solo después de que el usuario haya visto el borrador entero y diga que sí.
`provenance`	No	De cada norma, cifra o fecha que afirmas: de dónde sale (nota con su ruta, fuente oficial o tu conocimiento), o «sin fuente» (máx. 1.500).
`transcript`	No	La conversación en Markdown, con «Usuario:» e «IA:» al principio de cada turno (máx. 60000).
`unverified`	No	Lo que no se ha probado o comprobado, y cómo se podría comprobar (máx. 1.000).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026

addedInput schema / properties / brain_use

Added value: +{
+  "description": "Cuántas notas del brain has usado y qué aportas tú que no está en ninguna. Si es cero, di cero (máx. 1.000).",
+  "type": "string"
+}

addedInput schema / properties / provenance

Added value: +{
+  "description": "De cada norma, cifra o fecha que afirmas: de dónde sale (nota con su ruta, fuente oficial o tu conocimiento), o «sin fuente» (máx. 1.500).",
+  "type": "string"
+}

addedInput schema / properties / unverified

Added value: +{
+  "description": "Lo que no se ha probado o comprobado, y cómo se podría comprobar (máx. 1.000).",
+  "type": "string"
+}

First observedNov 8, 2026

TDQS

A4.4/5.0

Behavior3/5

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

The annotations already state readOnly=false, openWorld=true, non-idempotent and non-destructive, and the description is consistent with a write/send-to-external-party operation. Beyond that it adds genuinely useful traits: the mandatory two-step confirmation loop, that nothing is stored in the user's brain, and privacy constraints (no claves, contraseñas ni datos de terceros). It does not explain what the first call returns in detail or any rate/error behavior, so it stops short of the richest disclosure.

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?

Front-loaded with purpose, then triggers, then the step-by-step procedure, then field guidance and privacy rules; every clause carries functional information and none is redundant filler. It is delivered as one dense paragraph with heavy semicolon chaining, which makes the two-step sequence slightly harder to scan than it could be with discrete steps.

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 10-parameter, non-idempotent, externally-facing send with no output schema, the description covers the workflow (both steps and the edit loop), the intent of every free-text field, the privacy boundary, and the non-side-effect on the user's brain. An agent has enough to invoke it correctly without guessing.

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 baseline is 3, and every parameter already has a documented max-length purpose in the schema. The description still earns extra credit by adding meaning the schema lacks: summary is 'en tus palabras, en pocas líneas', transcript must be faithful with Usuario/IA labels and must not be summarized inside, and the too-long fallback routes the omission into note.

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 (prepara y envía) plus a concrete resource (un handoff de ESTA conversación) and a named recipient (Carlos, quien creó MemoryBrain). It also distinguishes itself from siblings that persist data by declaring 'No guarda nada en el cerebro del usuario', so an agent can tell it apart from add_learning/capture without opening schemas.

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?

Enumerates the exact trigger conditions (el usuario quiere pasarle/mandarle/compartir con Carlos lo hablado, un fallo, una duda, un resultado, o Carlos se lo pidió) and adds a hard prerequisite (cargar antes la skill handoff con get_skill). It also spells out the exclusion path: no confirmed → show draft → only on 'sí' → repeat with confirmed:true → if changes, loop back.

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.