MindNode를 Claude 및 모든 AI 에이전트에 연결하세요 — API도, AppleScript도, 내보낼 수 있는 파일도 없는 마인드 매핑 앱을 위한 MCP 서버입니다.
MindNode Next(2024+ 세대)는 모든 문서를 개인용 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
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.tsMCP 검사기로 디버그: 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는 라이브러리 blob을 자세히 들여다보기 위한 pretty-print 도구입니다.
쓰기 작업은 의도적으로 데이터베이스를 건드리지 않습니다(CloudKit 동기화가 있으므로, 손상시키면 안 됩니다). 새 문서는 MindNode 자체의 Markdown 가져오기 기능을 통해 open -a MindNode로 생성되며, 조용하고 무손실입니다.
get_mindmap은 CRDT 작업 스트림에서 텍스트를 재구성하는데, 위치 인코딩이 완전히 매핑되지 않았습니다: 많이 편집된 문자열은 약간 뒤섞여 나올 수 있고, 삭제된 노드는 (제목 없음)으로 남을 수 있습니다. 정확한 내용이 필요하면 get_mindmap_image를 사용하세요. create_mindmap으로 만든 문서는 무손실로 다시 읽힙니다.
create_mindmap은 MindNode를 실행합니다(가져오기는 앱 내에서 조용히 진행됩니다).
라이브러리는 항상 읽기 전용입니다. 형식은 MindNode 2026.4.4에서 검증되었습니다. 향후 MindNode 업데이트에서 필드 번호가 바뀔 수 있습니다 — 개요가 비어서 돌아오면 tools/spelunk.py 출력과 함께 이슈를 올려주세요.
노드 수준 편집(단일 노드 추가/이름 변경/삭제) 및 무손실 내보내기 — MindNode의 20가지 App Intent(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.
