Conecta MindNode con Claude y cualquier agente de IA: un servidor MCP para la aplicación de mapas mentales que no tiene API, ni AppleScript, ni archivos exportables.
MindNode Next (la generación 2024+ de MindNode) movió todos los documentos a una
biblioteca privada SQLite/CRDT y ofrece cero superficie de automatización: sin
diccionario de AppleScript, sin CLI, sin API en la nube, ni siquiera archivos .mindnode
en el disco. Este proyecto ha invertido el formato de almacenamiento para que los agentes
de IA puedan finalmente leer y crear mapas mentales:
Leer cualquier mapa mental como un esquema Markdown — directamente desde la biblioteca local de MindNode (SQLite → protobuf → Apple LZ4 → decodificación CRDT), de solo lectura, sin siquiera abrir la aplicación.
Ver el mapa renderizado exacto — las vistas previas JPEG propias de MindNode, con precisión de píxeles.
Crear nuevos mapas mentales a partir de esquemas Markdown (importación silenciosa en la aplicación).
Abrir cualquier mapa por nombre mediante el esquema de URL mindnode://.
Funciona con Claude Code, Claude Desktop y cualquier cliente MCP.
¿Buscas el MindNode clásico basado en archivos? Las herramientas más antiguas basadas en plist cubren los documentos
.mindnode; este servidor es para MindNode Next (2024+), la generación de biblioteca SQLite donde esos enfoques ya no funcionan. Verificado en MindNode 2026.4.4.
herramienta | qué hace |
| lista todos los mapas mentales de la biblioteca (título, id, modificado) |
| lee un mapa mental como esquema Markdown (decodificación CRDT de mejor esfuerzo) |
| vista previa JPEG renderizada por MindNode — verdad absoluta con precisión de píxeles |
| crea un nuevo mapa mental a partir de un esquema Markdown (importa mediante la aplicación) |
| abre un mapa mental en MindNode |
Related MCP server: Bruin
Requiere macOS con MindNode 2024+ y Node.js ≥ 24.
Claude Code:
claude mcp add --scope user mindnode -- npx -y mindnode-mcpClaude Desktop / cualquier cliente MCP (claude_desktop_config.json):
{
"mcpServers": {
"mindnode": {
"command": "npx",
"args": ["-y", "mindnode-mcp"]
}
}
}Desde el código fuente (Node ≥ 24 ejecuta TypeScript directamente, sin paso de compilación):
git clone https://github.com/jyuwaaw/mindnode-mcp.git
cd mindnode-mcp && npm install
claude mcp add --scope user mindnode -- node /path/to/mindnode-mcp/src/index.tsDepura con el inspector MCP: npm run inspect.
Mantengo un mapa mental diario (uno por día, además de mapas por proyecto) como mi memoria de trabajo — Raycast está configurado para invocar MindNode con una sola pulsación de tecla, así que capturar un pensamiento no cuesta nada. Este servidor cierra el bucle: al final del día un agente lee el mapa, lo convierte en un registro de trabajo o un borrador de blog, y puede sembrar el mapa del día siguiente a partir de hilos abiertos. Pregunta a Claude cosas como:
"lista mis mapas mentales"
"lee el mapa de hoy y redacta una actualización de standup"
"convierte este esquema en un mapa mental: …"
MindNode Next almacena todo en una biblioteca GRDB/SQLite dentro de su contenedor
sandbox. Cada documento es una instantánea base protobuf más un flujo de
lotes de operaciones CRDT, ambos envueltos en un pequeño sobre (campo 12345 =
versión, campo 678910 = carga útil — sí, de verdad) y comprimidos con el marco LZ4
de Apple (bloques bv41/bv4-/bv4$).
Este repositorio incluye un analizador protobuf sin esquema, un decodificador
Apple-LZ4 en TypeScript puro y un reconstructor de árbol que reproduce las
operaciones de creación de nodos y de texto. Las notas completas de ingeniería
inversa están en docs/FORMAT.md — si quieres construir tus
propias herramientas para MindNode, empieza ahí.
tools/spelunk.py imprime de forma legible cualquier blob de
la biblioteca para seguir investigando.
Las escrituras deliberadamente no tocan la base de datos (está sincronizada con
CloudKit; corromperla sería imperdonable). Los nuevos documentos pasan por el
importador Markdown propio de MindNode mediante open -a MindNode, que es
silencioso y sin pérdidas.
get_mindmap reconstruye el texto a partir de un flujo de operaciones CRDT cuya
codificación de posición no está completamente mapeada: las cadenas muy editadas
pueden volver ligeramente desordenadas, y los nodos eliminados pueden permanecer
como (sin título). Usa get_mindmap_image cuando la exactitud sea importante.
Los documentos creados mediante create_mindmap se leen sin pérdidas.
create_mindmap lanza MindNode (la importación ocurre en la aplicación, en
silencio).
La biblioteca se lee siempre en modo de solo lectura. Formato verificado en
MindNode 2026.4.4; una futura actualización de MindNode podría cambiar los números
de campo — abre un issue con la salida de tools/spelunk.py si los esquemas
vuelven vacíos.
Ediciones a nivel de nodo (añadir/renombrar/eliminar un solo nodo) y exportación sin pérdidas mediante los 20 App Intents de MindNode (CreateNode, EditNode, ExportDocument, …) envueltos en Shortcuts
Mapear la codificación de posición de texto CRDT y las eliminaciones para lecturas exactas
Títulos de carpetas, etiquetas/pegatinas, campos de notas
Create a new mind map in MindNode by importing Markdown. The first # heading becomes the central node; nested bullet lists (and deeper headings) become branches — write any consistent indentation, it is re-emitted at the four spaces per level MindNode requires. The document lands at the library root (placing it in a folder is not supported yet), and MindNode auto-renames the document if the title already exists — the central node keeps the requested title regardless.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Central node / document title | |
| markdown | Yes | Markdown outline. Example: `# Title\n- branch A\n - leaf\n- branch B`. A missing `#` heading is added from the title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and succeeds. It reveals actual behavior: the first `#` heading becomes the central node, nested bullets become branches, indentation is automatically re-emitted at four spaces, documents land at the library root, and auto-renaming occurs on title collision. This goes well beyond a bare 'create a mind map'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states core function, the second explains import semantics, the third covers placement and naming edge cases. The description is dense but not padded, with the most important purpose front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For two required parameters and no output schema or annotations, the description is quite complete. It covers creation behavior, placement, and naming. It does not mention return value or errors, which could matter since no output schema exists, but this gap is minor given the clear effect of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches parameters: `title` is clarified with the auto-rename behavior, and `markdown` is given explicit semantic mapping (headings to nodes, lists to branches, reindentation). This adds meaning that the schema does not fully capture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'Create[s] a new mind map in MindNode by importing Markdown,' and distinguishes itself from the sibling tools (list/get/get_image/open) by clearly being the creation operation. The agent can immediately tell this is the write/import tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear the tool is for creating new mind maps from Markdown, with a practical limitation ('placing it in a folder is not supported yet'). It does not explicitly name alternatives or state when not to use it, so it falls short of the highest bar for exclusionary guidance, but it provides ample usage context for a create operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a mind map's content as a Markdown outline (root heading + nested bullets), reconstructed from MindNode's local store. Best-effort: heavily edited text may be imperfect — cross-check with get_mindmap_image when exactness matters.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Document reference: a documentID (UUID) or a document title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately reveals that the content is reconstructed from MindNode's local store, that the result is best-effort, and that heavily edited text may be imperfect. This goes well beyond a bare read-only statement and prepares the agent for potential fidelity issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core behavior and output format are front-loaded, and the important limitation and cross-reference to the sibling tool are placed immediately after.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is complete: it specifies the output format, the source of the data, the fidelity limitation, and the recommended alternative when exactness is critical. No critical decision-relevant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is already fully described in the schema as a documentID or document title, so schema coverage is 100%. The tool description adds no additional parameter-specific detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Read') and resource ('a mind map's content') and specifies the output format as a Markdown outline with root heading and nested bullets. It also distinguishes this from the sibling get_mindmap_image by emphasizing textual outline reconstruction rather than an image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names get_mindmap_image as the alternative when exactness matters, giving the agent a clear decision rule for a common failure mode. It also implies this tool is appropriate when a Markdown outline is sufficient, even if heavily edited text may be imperfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return MindNode's own rendered preview (JPEG) of a mind map — the exact visual, useful to verify layout or ambiguous text.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Document reference: a documentID (UUID) or a document title | |
| appearance | No | Preview appearance (default light) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior. It discloses that the tool returns MindNode's rendered JPEG preview, conveying the output type and that it is non-mutating through the verb 'Return.' It also notes the exact visual nature, which helps set expectations. It omits delivery format details (e.g., binary vs. URL), but the core behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler: action, resource, output format, and use case are all included. The dash-separated clarification earns its place and does not repeat schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity image retrieval tool, the description plus schema covers the essential information: input document, optional appearance, and JPEG output. Since there is no output schema, some delivery details (e.g., binary payload or URL) are left unspecified, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters ('document' and 'appearance') are already well described in the schema. The description adds no new parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('MindNode's own rendered preview (JPEG) of a mind map'), clearly distinguishing this from sibling tools like get_mindmap (data) or open_mindmap (display). The addition 'the exact visual' reinforces that this tool returns an image, not structured content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'useful to verify layout or ambiguous text.' This tells an agent when to prefer this tool, though it does not explicitly mention when not to use it or name alternative siblings. That clear context without exclusions fits the upper-middle band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all mind maps in the local MindNode library (title, documentID, last modified). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| includeTrashed | No | Include trashed documents (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well by explicitly stating 'Read-only' and 'local MindNode library.' This prevents assumptions of network calls or side effects. It could still disclose default exclusion of trashed docs, but that is documented at the parameter level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the core behavior and return fields front-loaded; the read-only qualifier is a single appended word. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only listing tool with one optional documented parameter, the description covers scope, output fields, and safety. It stops short of mentioning explicit output structure or pagination, but these are minor for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, includeTrashed, has a clear description and default. The tool description adds no new parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact verb (List), resource (all mind maps in local MindNode library), and the return fields (title, documentID, last modified). This clearly distinguishes it from siblings like get_mindmap (single retrieval) and create_mindmap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The listing purpose is implied by 'List all mind maps,' and the read-only note signals a safe enumeration. However, it never explicitly says when to prefer this tool over get_mindmap/open_mindmap or what condition triggers the includeTrashed parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a mind map in the MindNode app (brings it to the foreground).
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Document reference: a documentID (UUID) or a document title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does add one useful behavioral detail (foregrounding the app), but it does not disclose prerequisites like MindNode being installed/running, failure behavior for missing documents, or whether the operation has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with zero filler. It communicates the action, target app, and the key behavioral effect without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, this is adequate but not complete: it covers the core action and the parameter is documented, but absent annotations it leaves ambiguity about what happens when the document is not found or whether the app must already be running.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single 'document' parameter is already described as either a documentID UUID or a title. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Open'), a clear resource ('a mind map'), and a concrete effect ('brings it to the foreground' in the MindNode app). This clearly differentiates it from sibling tools like list_mindmaps, get_mindmap, get_mindmap_image, and create_mindmap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of sibling tools, and no exclusions. The verb 'open' implies the intended use, but the description leaves selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1create_mindmapget_mindmapget_mindmap_imagelist_mindmapsopen_mindmapScored across 5 tools
Each tool targets a clear, distinct action: listing, reading text, reading image, creating, and opening. While get_mindmap and get_mindmap_image both retrieve content, one is text and one is visual, and the descriptions explicitly differentiate them.
All names follow a consistent verb_noun pattern: list_mindmaps, get_mindmap, get_mindmap_image, create_mindmap, open_mindmap. The one plural noun in list_mindmaps is natural because listing returns multiple items, and the pattern remains predictable.
Five tools is a well-scoped size for a MindNode local-library integration. Each tool serves a distinct user need, and none feels redundant or unnecessary.
The read, create, and open workflow is well covered, and get_mindmap_image adds valuable visual confirmation. However, there is no update, delete, rename, or folder-management operation, so the surface is more read/create-oriented than full lifecycle coverage.
Turn outlines and hierarchical notes into interactive mind maps through a hosted remote MCP server.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
