Skip to main content
Glama

Cargar una skill del cerebro

get_skill
Read-onlyIdempotent

Devuelve el texto de una skill: las instrucciones para una tarea concreta (extraer notas, importar chats o subrayados, proyectos, gusto visual…), con de quién es y su versión. Cárgala antes de la tarea que cubre y síguela; las demás tools dicen cuál toca. Los nombres disponibles salen en get_context. Con un nombre que no existe, devuelve un error con la lista de las que hay. Skills: doc-eval (Diagnostica un texto (email, memo, propuesta, update, PRD, post o artículo) con seis dimensiones, hard gates y la evidencia citada, y dice qué arreglar primero. Cárgala cuando pregunte si un texto está listo para enviar o publicar, o pida feedback sobre él. Para aplicar los arreglos es doc-improve; para escribir desde cero, doc-write.) · doc-improve (Edita un texto que ya existe para quitarle el relleno y los tics de IA sin perder la voz del autor, sus hechos ni su longitud, y devuelve el texto editado más qué ha cambiado. Cárgala cuando pida mejorar, limpiar o reescribir un texto, o cuando diga que suena a IA. Para escribir desde cero es doc-write; para puntuarlo, doc-eval.) · doc-write (Redacta un texto nuevo (email, memo, one-pager, propuesta, update, PRD, post o artículo) fijando antes para quién es y qué tiene que hacer quien lo lea, sin inventar nada que no venga del material o del usuario. Cárgala cuando pida escribir algo desde cero. Para editar un texto que ya existe es doc-improve; para puntuarlo, doc-eval.) · gusto-visual (Convierte las referencias visuales del usuario en notas de su cerebro sin guardar ninguna imagen. Lee un tablero o perfil público de Pinterest (o imágenes que pega en el chat), describe qué tiene cada una, le pregunta qué le gusta y guarda la nota con el enlace a la imagen, que se queda donde está. Cárgala cuando quiera darle su gusto visual, pegue un tablero de Pinterest, pegue imágenes que le gustan o pida diseñar algo «con su gusto».) · handoff (Prepara un handoff de esta conversación y se lo manda a Carlos para que la analice, sin que el usuario copie y pegue nada. Cárgala cuando el usuario diga que quiere pasarle, mandarle o enseñarle a Carlos lo que habéis hablado (un fallo, una duda, un resultado raro, una idea), o cuando Carlos le haya pedido que se lo pase.) · importar-chats (Pasa al cerebro del usuario lo que ya ha hablado con ChatGPT o Claude. Empieza por lo que el propio chat ya sabe de él (su memoria, sus conversaciones anteriores y, si la conversación está dentro de un proyecto, las instrucciones, archivos y chats de ese proyecto) y solo si eso da poco ofrece la importación a fondo, con la exportación de sus chats. Cárgala cuando quiera importar o pasar sus chats a MemoryBrain, diga «lo que ya sabes de mí», «guarda este proyecto en mi cerebro» o «extrae mis chats».) · open-brain-extract (Convierte una fuente que comparte el usuario (artículo, enlace, PDF, vídeo, podcast o texto) en notas atómicas para su Open Brain. Cárgala antes de llamar a feed_brain.) · open-brain-learn-session (Punto de entrada para aprender algo con el cerebro del usuario. Mira primero qué sabe ya, decide si toca contenido nuevo, práctica o evaluación, y lleva la sesión hasta una práctica real. Cárgala cuando diga que quiere aprender algo, que tiene un libro o un curso, que quiere practicar o repasar lo que leyó, o qué sabe sobre un tema.) · open-brain-retrieve (Responde con lo que sabe el Open Brain del usuario: qué tiene sobre una idea, notas relacionadas, conexiones entre dominios, contradicciones. Cárgala antes de buscar con search_brain para contestar.) · people-radar (Analiza un post de LinkedIn, X o un blog que el usuario pega, decide si tiene algo propio y no obvio que aportar apoyándose en su cerebro, y si lo tiene prepara como mucho tres ángulos de comentario. Cárgala cuando pegue un post y pregunte si comentar, pida un comentario o una respuesta, o diga que alguien le ha contestado. Nunca publica nada.) · practicar-idiomas (Practica un idioma (empieza por el inglés) hablado y escrito con el usuario, recuerda sus errores de una sesión a otra y prepara situaciones reales de su trabajo para ensayarlas. Cárgala cuando diga que quiere practicar, mejorar o aprender inglés u otro idioma, ensayar una reunión, una entrevista o un correo en otro idioma, o repasar sus errores.) · proyectos (Lleva los proyectos y tareas del usuario para que no tenga que sostenerlos en la cabeza. Qué tiene en marcha, en qué punto va cada cosa, el siguiente paso y lo que falta, y lo retoma en cualquier conversación, en ChatGPT o en Claude. Cárgala cuando quiera vaciar la cabeza, apuntar un proyecto, preguntar en qué estaba o qué toca ahora, o cuente un avance de algo suyo.) · subrayados-kindle (Pasa al cerebro del usuario lo que ha subrayado en Kindle, con la frase original de cada subrayado, el libro, el autor y la página, y sus propias notas del Kindle aparte. Por archivo (My Clippings.txt o el cuaderno exportado) o, si trabajas dentro de su navegador, leyendo su página de notas de Amazon. Cárgala cuando quiera importar sus subrayados, highlights o notas de Kindle, diga «extrae mis subrayados», «trae lo que he subrayado esta semana» o pregunte cómo traer lo que ha leído en Kindle.)

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

Input Schema

NameRequiredDescriptionDefault
nameYesNombre de la skill, tal como lo dan get_context o la tool que la pide (p. ej. open-brain-extract, proyectos, importar-chats).
brainNoSolo para una skill de otra persona: el cerebro conectado que la comparte (u-xxxxxx, de list_brains). Tiene que estar aprobada antes (review_skill).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / brain
      Added value: +{
      +  "description": "Solo para una skill de otra persona: el cerebro conectado que la comparte (u-xxxxxx, de list_brains). Tiene que estar aprobada antes (review_skill).",
      +  "type": "string"
      +}
    • addedInput schema / properties / name / description
      Added value: +"Nombre de la skill, tal como lo dan get_context o la tool que la pide (p. ej. open-brain-extract, proyectos, importar-chats)."
  2. Changed1 schema field changed
    • changedInput schema / properties / name / enum
      Previous value: -[
      -  "doc-eval",
      -  "doc-improve",
      -  "doc-write",
      -  "gusto-visual",
      -  "handoff",
      -  "importar-chats",
      -  "open-brain-extract",
      -  "open-brain-learn-session",
      -  "open-brain-retrieve",
      -  "people-radar",
      -  "proyectos",
      -  "subrayados-kindle"
      -]New value: +[
      +  "doc-eval",
      +  "doc-improve",
      +  "doc-write",
      +  "gusto-visual",
      +  "handoff",
      +  "importar-chats",
      +  "open-brain-extract",
      +  "open-brain-learn-session",
      +  "open-brain-retrieve",
      +  "people-radar",
      +  "practicar-idiomas",
      +  "proyectos",
      +  "subrayados-kindle"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered. The description still adds real behavior: an unknown name returns an error containing the list of available skills, and the brain parameter only works for a shared brain that was approved beforehand — information absent from the annotations.

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?

The purpose and the call-before-the-task rule are front-loaded, which is good, but the bulk of the text is a 13-entry catalog that dwarfs the two-parameter operation and repeats cross-references ('para puntuarlo, doc-eval') across entries. Each entry is individually useful, yet the volume makes the definition harder to scan than a compact routing line plus the enum would 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?

For a read-only loader with no output schema, the agent still learns what is returned (skill text, owner, version), where to discover valid names, what happens on a bad name, and the prerequisite for the shared-brain case. Nothing needed to invoke it correctly is missing.

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 100%, so the baseline is 3, but the description goes further by explaining what each of the 13 enum values actually does and when it applies, which is meaning the schema only hints at through bare identifiers. The brain parameter's provenance and approval requirement are restated rather than expanded, which keeps this from a 5.

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?

Opens with a concrete verb+resource: 'Devuelve el texto de una skill: las instrucciones para una tarea concreta', and states what comes back (instructions, owner, version). It also separates itself from adjacent tools by pointing to get_context for the list of available names, so an agent knows this is a loader, not a catalog or saver.

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 an explicit rule — 'Cárgala antes de la tarea que cubre y síguela' — plus the routing signal that the other tools name which skill applies. Every enumerated skill carries its own 'Cárgala cuando…' trigger and names alternatives (e.g., doc-eval vs doc-improve vs doc-write), which is the strongest form of when-to-use/when-not guidance.

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.