Подключите MindNode к Claude и любому ИИ-агенту — MCP-сервер для приложения для создания интеллект-карт, у которого нет ни API, ни AppleScript, ни экспортируемых файлов.
MindNode Next (поколение MindNode 2024+) перенёс все документы в приватную библиотеку SQLite/CRDT и поставляется с нулевой поверхностью автоматизации: ни словаря AppleScript, ни CLI, ни облачного API, даже .mindnode-файлов на диске больше нет. Этот проект реконструировал формат хранения, чтобы ИИ-агенты наконец могли читать и создавать интеллект-карты:
Читать любую интеллект-карту как Markdown-структуру — прямо из локальной библиотеки MindNode (SQLite → protobuf → Apple LZ4 → CRDT decode), только для чтения, даже не запуская приложение.
Видеть точное отображение карты — собственные JPEG-превью MindNode, попиксельно точные.
Создавать новые интеллект-карты из Markdown-структур (тихий импорт внутри приложения).
Открывать любую карту по имени через URL-схему mindnode://.
Работает с Claude Code, Claude Desktop и любым MCP-клиентом.
Ищете классический файловый MindNode? Более старые инструменты на основе plist работают с
.mindnode-документами; этот сервер предназначен для MindNode Next (2024+), поколения с SQLite-библиотекой, где эти подходы больше не работают. Проверено на MindNode 2026.4.4.
инструмент | что делает |
| список всех интеллект-карт в библиотеке (название, id, дата изменения) |
| чтение интеллект-карты как Markdown-структуры (декодирование CRDT по мере возможности) |
| собственный отрендеренный JPEG-превью MindNode — попиксельно точный эталон |
| создание новой интеллект-карты из Markdown-структуры (импорт через приложение) |
| открыть интеллект-карту в MindNode |
Related MCP server: Bruin
Требуется macOS с MindNode 2024+ и Node.js ≥ 24.
Claude Code:
claude mcp add --scope user mindnode -- npx -y mindnode-mcpClaude Desktop / любой MCP-клиент (claude_desktop_config.json):
{
"mcpServers": {
"mindnode": {
"command": "npx",
"args": ["-y", "mindnode-mcp"]
}
}
}Из исходников (Node ≥ 24 запускает TypeScript напрямую, без шага сборки):
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.tsОтладка с помощью MCP-инспектора: npm run inspect.
Я веду ежедневную интеллект-карту (одну на день, плюс карты по проектам) как рабочую память — Raycast настроен так, чтобы вызывать MindNode одним нажатием клавиши, поэтому зафиксировать мысль ничего не стоит. Этот сервер замыкает цикл: в конце дня агент читает карту, превращает её в рабочий журнал или черновик блога и может наполнить завтрашнюю карту из открытых тем. Спрашивайте Claude, например:
"список моих интеллект-карт"
"прочитай сегодняшнюю карту и составь обновление для стендапа"
"преврати эту структуру в интеллект-карту: …"
MindNode Next хранит всё в библиотеке GRDB/SQLite внутри своего sandbox-контейнера. Каждый документ — это protobuf базовый снимок плюс поток CRDT пакетов операций, оба обёрнуты в крошечный конверт (поле 12345 = версия, поле 678910 = полезная нагрузка — да, именно так) и сжаты с помощью фрейминга Apple LZ4 (блоки bv41/bv4-/bv4$).
В этом репозитории есть парсер protobuf без схемы, декодер Apple-LZ4 на чистом TypeScript и реконструктор дерева, который воспроизводит операции создания узлов и текстовые операции. Полные заметки по обратной разработке находятся в docs/FORMAT.md — если хотите создать собственный инструментарий для MindNode, начните там. tools/spelunk.py красиво выводит любой библиотечный blob для дальнейшего изучения.
Запись намеренно не касается базы данных (она синхронизируется через CloudKit; повредить её было бы непростительно). Новые документы проходят через собственный импортёр Markdown в MindNode с помощью open -a MindNode — это тихо и без потерь.
get_mindmap восстанавливает текст из потока CRDT-операций, кодировка позиций которого изучена не полностью: сильно отредактированные строки могут вернуться слегка перепутанными, а удалённые узлы могут остаться как (untitled). Используйте get_mindmap_image, когда важна точность. Документы, созданные через create_mindmap, читаются обратно без потерь.
create_mindmap запускает MindNode (импорт происходит внутри приложения, тихо).
Библиотека читается только для чтения, всегда. Формат проверен на MindNode 2026.4.4; будущее обновление MindNode может сдвинуть номера полей — создайте issue с выводом tools/spelunk.py, если структуры возвращаются пустыми.
Редактирование на уровне узлов (добавление/переименование/удаление одного узла) и экспорт без потерь через 20 App Intents MindNode (CreateNode, EditNode, ExportDocument, …), обёрнутых в Shortcuts
Разобрать кодировку позиций текста в CRDT и удаления для точного чтения
Заголовки папок, теги/стикеры, поля заметок
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.
