MemoryBrain

Paso del onboarding

onboarding_step

Idempotent

Pinta la tarjeta de comparación del onboarding y guarda la pregunta y tus respuestas en su estado de onboarding. stage «sin»: la pregunta del usuario y tu respuesta SIN buscar en su cerebro, en 3 a 5 líneas. stage «con»: tu respuesta a la misma pregunta apoyada en su cerebro, después de guardar lo suyo con feed_brain y leerlo con read_note, y los ids de las notas que has usado. No repitas en el chat lo que pinta la tarjeta.

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": {
      "stage": "<stage>",
      "question": "<question>",
      "answer": "<answer>"
    },
    "name": "onboarding_step"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Solo con «con»: ids de las notas de su cerebro que has usado (de search_brain).
`stage`	Yes	sin: respuesta sin buscar en su cerebro. con: respuesta apoyada en sus notas (pide notes).
`answer`	Yes	Tu respuesta, en texto llano o Markdown sencillo.
`question`	Yes	La pregunta del usuario, tal cual.

Output Schema

Name	Required	Description	Default
`view`	No
`stage`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

addedInput schema / properties / stage / description

Added value: +"sin: respuesta sin buscar en su cerebro. con: respuesta apoyada en sus notas (pide notes)."

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already state it is non-destructive, idempotent, and not read-only, and the description adds that it writes onboarding state and renders a card. The instruction not to repeat the card content in chat is useful behavioral context beyond the annotations. It does not cover permissions or what happens if state already exists, despite the idempotent hint.

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?

Front-loads the core action, then splits the two stages into parallel clauses, ending with a single do-not instruction. Every sentence carries operational information with no filler.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the two-stage workflow is well covered. However, for a state-persisting tool it says nothing about re-invocation behavior or what the onboarding state does after this step, leaving a gap given the idempotent hint.

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 coverage is already 100 percent, so the baseline is 3, but the description adds meaning the schema lacks: the 3-to-5-line constraint for 'sin', the requirement that 'con' answers be grounded in notes whose ids are reported, and the ordering of feed_brain before read_note.

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?

States a specific verb and resource: paints the onboarding comparison card and persists the question and answer into onboarding state. The two 'stage' modes separate it from siblings like feed_brain or read_note, though the 'pinta la tarjeta' rendering role could be clearer about what the caller sees.

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?

Gives concrete conditions for each stage: 'sin' means answering without searching the brain, 'con' means answering grounded in notes after feeding and reading them. It even names the prerequisite siblings (feed_brain, read_note) in order, but offers no explicit when-not or failure handling.

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.