Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mindnode-mcp Read today's mind map and draft a standup update."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect MindNode to Claude and any AI agent — an MCP server for the mind-mapping app that has no API, no AppleScript, and no exportable files.
MindNode Next (the 2024+ generation of MindNode) moved all documents into a
private SQLite/CRDT library and ships zero automation surface: no
AppleScript dictionary, no CLI, no cloud API, not even .mindnode files on
disk anymore. This project reverse-engineered the storage format so AI agents
can finally read and create mind maps:
Read any mind map as a Markdown outline — straight from MindNode's local library (SQLite → protobuf → Apple LZ4 → CRDT decode), read-only, without even launching the app.
See the exact rendered map — MindNode's own preview JPEGs, pixel-perfect.
Create new mind maps from Markdown outlines (silent in-app import).
Open any map by name via the mindnode:// URL scheme.
Works with Claude Code, Claude Desktop, and any MCP client.
Looking for the classic file-based MindNode? Older plist-based tools cover
.mindnodedocuments; this server is for MindNode Next (2024+), the SQLite-library generation where those approaches no longer work. Verified on MindNode 2026.4.4.
tool | what it does |
| list all mind maps in the library (title, id, modified) |
| read a mind map as a Markdown outline (best-effort CRDT decode) |
| MindNode's own rendered JPEG preview — pixel-perfect ground truth |
| create a new mind map from a Markdown outline (imports via the app) |
| open a mind map in MindNode |
Related MCP server: macos-screen-mcp
Requires macOS with MindNode 2024+ and Node.js ≥ 24.
Claude Code:
claude mcp add --scope user mindnode -- npx -y mindnode-mcpClaude Desktop / any MCP client (claude_desktop_config.json):
{
"mcpServers": {
"mindnode": {
"command": "npx",
"args": ["-y", "mindnode-mcp"]
}
}
}From source (Node ≥ 24 runs the TypeScript directly, no build step):
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.tsDebug with the MCP inspector: npm run inspect.
I keep a daily mind map (one per day, plus per-project maps) as my working memory — Raycast is set up to summon MindNode with a single keystroke, so capturing a thought costs nothing. This server closes the loop: at the end of the day an agent reads the map, turns it into a work log or blog draft, and can seed tomorrow's map from open threads. Ask Claude things like:
"list my mind maps"
"read today's map and draft a standup update"
"turn this outline into a mind map: …"
MindNode Next stores everything in a GRDB/SQLite library inside its sandbox
container. Each document is a protobuf base snapshot plus a stream of
CRDT operation batches, both wrapped in a tiny envelope (field 12345 =
version, field 678910 = payload — yes, really) and compressed with Apple's
LZ4 framing (bv41/bv4-/bv4$ blocks).
This repo carries a schema-less protobuf parser, a pure-TypeScript Apple-LZ4
decoder, and a tree reconstructor that replays node-creation and text ops.
The full reverse-engineering notes live in docs/FORMAT.md —
if you want to build your own MindNode tooling, start there.
tools/spelunk.py pretty-prints any library blob for
further digging.
Writes deliberately do not touch the database (it's CloudKit-synced;
corrupting it would be unforgivable). New documents go through MindNode's own
Markdown importer via open -a MindNode, which is silent and lossless.
get_mindmap reconstructs text from a CRDT op stream whose position
encoding isn't fully mapped: heavily edited strings can come back slightly
scrambled, and deleted nodes may linger as (untitled). Use
get_mindmap_image when exactness matters. Documents created via
create_mindmap read back losslessly.
create_mindmap launches MindNode (import happens in-app, silently). It
always lands the new document at the library root — targeting a folder
needs the App Intents route (see Roadmap) — and MindNode auto-renames the
document when the title already exists (the central node keeps the title
you asked for). There is no tool yet for adding nodes to an existing map,
renaming, or deleting.
If an import produces nothing, check MindNode itself: a modal dialog in the
app blocks every subsequent open/import, and open still exits 0. Only
Markdown imports work this way — MindNode registers as a viewer for OPML,
FreeMind and TaskPaper, but opening those files is silently ignored.
The library is read read-only, always. Format verified on MindNode
2026.4.4; a future MindNode update could shift field numbers — file an
issue with tools/spelunk.py output if outlines come back empty.
Node-level edits (add/rename/delete a single node) and lossless export via MindNode's 20 App Intents (CreateNode, EditNode, ExportDocument, …) wrapped in Shortcuts
Map the CRDT text-position encoding and deletions for exact reads
Folder titles, tags/stickers, notes fields
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. Dates show when Glama detected each change.
v0.1.1create_mindmapget_mindmapget_mindmap_imagelist_mindmapsopen_mindmapEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jyuwaaw/mindnode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
