Skip to main content
Glama

Buscar en tu cerebro

search_brain
Read-only

Busca en el cerebro del usuario y devuelve candidatas: título, tipo, términos y el principio de cada nota. Con una URL dice si esa fuente ya está. Antes de usarla para contestar, carga la skill open-brain-retrieve con get_skill. Lo esencial, por si no la cargas: llama antes a get_context; pon en expand 2 a 5 reformulaciones (sinónimo, otro idioma, formulación de fallo) en vez de buscar una vez; cada candidata dice en channels por qué salió, y neighbors trae las conectadas por el grafo con las primeras; lee enteras con read_note solo las 4 a 6 mejores y nunca cites una que no has leído; cita cada nota por lo que afirma, nunca por su id; si no hay nada, dilo y no contestes de memoria.

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": {
      "query": "<query>"
    },
    "name": "search_brain"
  }
}

Input Schema

NameRequiredDescriptionDefault
kNoCuántas candidatas (8 por defecto).
kindNoSolo notas de este tipo. Con «referencia», sus referencias visuales: úsalo para partir de su gusto antes de diseñar algo.
brainNoEn qué cerebro: «tuyo» (el del usuario, por defecto), el id de uno conectado (list_brains) o «todos».
queryYesPalabras o una URL.
expandNoDe 2 a 5 formas más de decir lo mismo: sinónimos, el otro idioma, el problema en vez de la solución. Es lo que más mejora la búsqueda.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: `channels` explains why a candidate surfaced, `neighbors` exposes graph-connected notes, and there is an explicit empty-result path. It does not cover pagination or ranking limits, hence not a top mark.

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?

Purpose is front-loaded in the first sentence, but the rest is a dense run-on of procedural instructions that largely duplicate the referenced skill, including a self-aware 'por si no la cargas' preamble. Every clause is useful, yet the block is longer than a tool description needs to be.

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?

There is no output schema, and the description compensates by describing the returned fields (título, tipo, términos, principio, channels, neighbors) and the URL-existence check. For a 5-parameter read-only search tool, an agent has everything needed to invoke it correctly.

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%, so baseline would be 3, but the description adds meaning beyond the schema: it specifies what kind of reformulations to place in `expand` (sinónimo, otro idioma, formulación de fallo) and frames `expand` as the single biggest search-quality lever. `k` and `brain` are left mostly to 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 (search the user's brain) and precisely enumerates what comes back: título, tipo, términos, and the opening of each note, plus the URL-lookup mode. It is clearly distinguishable from siblings like read_note (full read), get_context (prior step), and list_brains (brain enumeration).

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?

Explicit when-to-use chain: call get_context first, load open-brain-retrieve via get_skill, use expand with 2–5 reformulations instead of a single query, read only the 4–6 best candidates with read_note, and state that nothing was found rather than answering from memory. It also names the alternative tools that follow this one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.