将 MindNode 连接到 Claude 及任何 AI 智能体——一个 为这款没有 API、没有 AppleScript、也没有可导出文件的思维导图应用打造的 MCP 服务器。
MindNode Next（2024+ 一代的 MindNode）将所有文档迁移到了私有
SQLite/CRDT 库中，并且零自动化接口：没有 AppleScript 字典、没有 CLI、
没有云 API，甚至磁盘上也不再存在 .mindnode 文件。本项目逆向工程了其存储
格式，让 AI 智能体终于能够读取和创建思维导图：
读取任何思维导图为 Markdown 大纲——直接从 MindNode 的本地库中读取 （SQLite → protobuf → Apple LZ4 → CRDT 解码），只读操作，甚至无需启动应用。
查看精确的渲染图——MindNode 自带的预览 JPEG，像素级完美。
创建新的思维导图（从 Markdown 大纲静默导入到应用中）。
通过 mindnode:// URL 方案按名称打开任何导图。
适用于 Claude Code、Claude Desktop 以及任何 MCP 客户端。
在寻找基于经典文件的 MindNode？旧版基于 plist 的工具可以处理
.mindnode文档；本服务器面向 MindNode Next（2024+），即 SQLite 库这一代，旧方法已不再适用。已在 MindNode 2026.4.4 上验证。
工具 | 功能 |
| 列出库中所有思维导图（标题、ID、修改时间） |
| 将思维导图读取为 Markdown 大纲（尽力而为的 CRDT 解码） |
| MindNode 自带的渲染 JPEG 预览——像素级完美的真实结果 |
| 从 Markdown 大纲创建新的思维导图（通过应用导入） |
| 在 MindNode 中打开思维导图 |
Related MCP server: Bruin
需要装有 MindNode 2024+ 的 macOS 和 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 库中。
每个文档是一个 protobuf 基础快照，外加一串 CRDT 操作批次，
两者都包裹在一个微型信封中（字段 12345 = 版本，字段 678910 = 载荷——
没错，就是这样），并使用 Apple 的 LZ4 帧格式（bv41/bv4-/bv4$ 块）
压缩。
本仓库包含一个无模式的 protobuf 解析器、一个纯 TypeScript 的 Apple-LZ4
解码器，以及一个重放节点创建和文本操作的重建器。
完整的逆向工程笔记见 docs/FORMAT.md——
如果你想构建自己的 MindNode 工具，从这里开始。
tools/spelunk.py 可以美化打印任何库数据块，
便于进一步挖掘。
写入操作刻意不触碰数据库（它由 CloudKit 同步；损坏它将不可原谅）。
新文档通过 MindNode 自带的 Markdown 导入器（open -a MindNode）创建，
该过程静默且无损。
get_mindmap 从 CRDT 操作流中重建文本，而该流的位置编码尚未完全
映射：大量编辑过的字符串可能略有错乱，已删除的节点可能残留为
(untitled)。当精确性至关重要时，请使用 get_mindmap_image。
通过 create_mindmap 创建的文档可以无损读回。
create_mindmap 会启动 MindNode（导入在应用内静默完成）。
库始终以只读方式访问。格式已在 MindNode 2026.4.4 上验证；
未来的 MindNode 更新可能改变字段编号——如果大纲读回为空，
请附上 tools/spelunk.py 的输出提交 issue。
节点级编辑（添加/重命名/删除单个节点），以及通过 MindNode 的 20 个 App Intents（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.
