Enables cloud sync of the mindmap to a private GitHub Gist for backup and restore.
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., "@mindkeeper-mcp Capture idea: improve onboarding flow"
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.
An MCP server that captures ideas from conversations and organises them into a persistent mindmap. Ideas are stored as nodes that can be linked to a parent, tagged, searched, exported, and synced to the cloud — surviving across sessions.
Data is stored in ~/.mindkeeper/mindmap.json with atomic writes and automatic backups.
Persistent — mindmap survives across conversations and restarts
Hierarchical — nest ideas under parents to build tree structure
Searchable — weighted full-text search across text and tags
Deduplication — same idea under the same parent is never added twice
Safe writes — atomic temp-file → backup → rename strategy
Concurrency-safe — serialised write queue prevents file corruption
Export — Markdown, Mermaid diagram, OPML, JSON, or interactive HTML (with PNG/SVG download)
Import — build a mindmap from your Claude.ai conversation history
Cloud sync — backup and restore via private GitHub Gist
Related MCP server: Open-Brain
npm install -g mindkeeper-mcpgit clone https://github.com/icedsg/mindkeeper-mcp
cd mindkeeper-mcp
npm install
npm run buildEdit claude_desktop_config.json. The quickest way to open it: in Claude Desktop, go to Settings → Developer → Edit Config.
Alternatively, find the file at:
Platform | Location |
macOS |
|
Windows |
|
Linux |
|
Global install:
{
"mcpServers": {
"mindkeeper": {
"command": "mindkeeper-mcp"
}
}
}Local install (absolute path):
{
"mcpServers": {
"mindkeeper": {
"command": "node",
"args": ["/absolute/path/to/mindkeeper-mcp/build/index.js"]
}
}
}After editing the config, restart Claude Desktop for the server to connect.
# Global install
claude mcp add mindkeeper -- mindkeeper-mcp
# Local install
claude mcp add mindkeeper -- node /path/to/mindkeeper-mcp/build/index.jsAdd this to your Claude Desktop system prompt (Settings → Profile → Custom Instructions) to make mindkeeper capture your topics automatically:
You have mindkeeper-mcp connected.
- After each of my messages, if I mention a new topic, question, goal, or interest — call add_idea to record it. Only capture what I say, never your own responses.
- Before adding, call search_ideas to avoid duplicates.Tool | Description |
| Capture a new idea, optionally attached to a parent node |
| Edit the text or tags of an existing idea |
| Remove an idea; children are orphaned (kept, not deleted) |
| Full-text search across idea text and tags |
| Retrieve the full tree, or a subtree from a given node |
| Export as a nested Markdown list |
| Export as a Mermaid flowchart — paste into GitHub, Notion, or Obsidian |
| Export as OPML — import into MindNode, OmniOutliner, or XMind |
| Export raw JSON — use with the online visualizer |
| Generate a self-contained interactive HTML file saved to |
| Parse a |
| Push or pull the mindmap to/from a private GitHub Gist |
| Show current cloud sync configuration |
Capture a top-level idea:
add_idea text="Product strategy for Q3" tags=["strategy","q3"]Add a sub-idea under an existing node:
add_idea text="Launch in EU market" parentId="<id from previous call>" tags=["launch"]Refine an idea:
update_node nodeId="<id>" newText="Launch in EU market — target Germany first"Find related ideas:
search_ideas query="EU launch"See the whole map:
get_mindmapExport for a document:
export_markdownVisualize interactively:
export_html # opens in browser — drag, zoom, download PNG or SVG from the toolbarOr paste into an online renderer:
export_json # drop the output into the visualizer at the project websiteCreate ~/.mindkeeper/config.json:
{
"cloud": {
"provider": "github_gist",
"token": "ghp_YOUR_PERSONAL_ACCESS_TOKEN"
}
}Generate a token at github.com/settings/tokens with the gist scope. The first sync_cloud direction="push" auto-creates a private Gist and saves the gistId back to config.
Export your mindmap as JSON and drop it into the browser-based visualizer at icedsg.github.io/mindkeeper-mcp/visualize.html for zoomable, draggable, multi-layout exploration.
Turn your entire Claude.ai conversation history into a structured mindmap in three steps.
Open claude.ai and go to Settings → Account
Scroll to Export Data and click Export
Claude emails you a download link within a few minutes
Download the ZIP and unzip it — find conversations.json inside
Tell Claude:
Import my Claude export from /path/to/conversations.json into my mindmapReplace the path with the actual location:
Windows: C:\Users\YourName\Downloads\claude-export\conversations.json
Mac/Linux: /Users/YourName/Downloads/claude-export/conversations.json
Claude reads every conversation, clusters them by theme, and populates the mindmap. Trivial or very short conversations are skipped automatically.
Export the mindmap as HTMLThe HTML file is saved to ~/.mindkeeper/mindmap-export.html and opens in any browser — no server needed. Inside the file, use the toolbar buttons to download a PNG or SVG image.
The mindmap is stored in ~/.mindkeeper/mindmap.json. A backup is kept at ~/.mindkeeper/mindmap.json.bak and is overwritten on every save.
To reset: delete or rename mindmap.json. The server creates a fresh empty map on next use.
npm run dev # tsx watch mode — restarts on file change
npm run build # compile TypeScript to ./build
npm test # run test suite (requires bash)Server not found after global install
Ensure npm's global bin directory is on your PATH:
npm config get prefix # e.g. /usr/local
# Add /usr/local/bin to PATH if missingPermission denied on ~/.mindkeeper
mkdir -p ~/.mindkeeper
chmod 755 ~/.mindkeeperMindmap is empty after restart
Check the file exists and is valid JSON:
cat ~/.mindkeeper/mindmap.json | node -e "process.stdin.resume(); let d=''; process.stdin.on('data',c=>d+=c); process.stdin.on('end',()=>console.log(JSON.parse(d).rootId))"If the file is corrupt, restore from backup:
cp ~/.mindkeeper/mindmap.json.bak ~/.mindkeeper/mindmap.jsonstdio errors in Claude Desktop logs
The server logs all operations to stderr (visible in Claude Desktop's MCP logs). Normal log lines start with [mindkeeper]. Anything else is an unexpected error.
MIT License — see LICENSE.
Open-source dependencies:
Package | License | Used for |
MIT | MCP server protocol | |
MIT | Node ID generation | |
ISC | Force graph & tree views in the web visualizer |
Original work:
mindkeeper-map.js — the interactive mindmap renderer used in the exported HTML and web visualizer is original code with no external dependencies. Algorithms: slot-based tree layout, cubic-bezier links, canvas measureText node sizing, per-node drag coexisting with canvas pan.
Capture a new idea or concept into the persistent mindmap. ONLY use this when the user themselves has expressed an idea, question, goal, task, topic, or interest — including casual searches ('how to cook biryani'), projects they mention, or anything they bring up. NEVER invent, generate, or seed example nodes. NEVER add content Claude thought of. Before adding, check if the same idea already exists (use search_ideas) to avoid duplicates. Attach it to an existing node with parentId to build hierarchical structure. Returns the new node with its ID (needed for future parentId references).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The idea or concept text to capture | |
| parentId | No | ID of an existing node to attach this idea under. Omit to create a root-level idea. | |
| tags | No | Optional topic tags. Leading # is stripped and values are lowercased automatically. Pass either ["roadmap", "q3"] or ["#roadmap", "#q3"] — both work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses persistence to mindmap, no invention policy, and return of node ID. With no annotations, it covers major behavioral traits well, though could mention idempotency or error handling.
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 a single, well-organized paragraph with clear directives, no wasted words, and front-loaded with the main purpose.
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 tool with 3 parameters, 1 required, and no output schema, the description covers usage constraints, duplicate prevention, hierarchical structure, and return value, making it complete for its 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 has 100% coverage, so description adds minimal parameter detail beyond usage context. The tags parameter note about stripping # and lowercasing is an extra, but overall baseline is 3.
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 the tool captures ideas into a persistent mindmap for user-expressed content, distinguishing it from sibling tools like search_ideas or delete_node by specifying when to use it.
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?
Provides explicit when-to-use (user's own ideas, questions, tasks) and when-not-to-use (no inventing, no example nodes). Also advises checking for duplicates with search_ideas and attaching with parentId for hierarchy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether cloud sync is configured and show the current config (token is masked). Returns the provider, gistId (if any), and setup instructions if not configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions token masking and return values (provider, gistId, setup instructions). Does not disclose potential side effects or authentication needs, but being a read-only check, it is fairly transparent.
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?
Two sentences, no wasted words. Front-loaded with key verb 'Check' and immediate details.
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?
With no output schema, description explains return values (provider, gistId, setup instructions). Lacks mention of error conditions or prerequisites, but adequate for a simple status 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?
No parameters exist (baseline 4). Description adds meaning by specifying what the tool returns (status details) beyond the schema.
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?
Description clearly states it checks cloud sync configuration and shows current config with details like provider, gistId, and setup instructions. It is specific and distinct from sync_cloud which performs the sync action.
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?
Description implies when to use (to check status) but does not explicitly state when not to use or provide alternatives. No exclusions or comparisons to sibling tools like sync_cloud.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a node from the mindmap. Child nodes are orphaned (kept in the map but disconnected from the tree). Use search_ideas first if you are unsure of the nodeId.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the node to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that child nodes become orphaned, which is important behavioral information not evident from the schema or annotations (which are absent). Could add more about irreversibility or confirmation, but sufficient.
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?
Two concise sentences with no unnecessary words; every sentence adds value.
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?
Covers the essential: action, effect on children, and how to obtain input. Lacks information about output or undo, but acceptable for a simple delete.
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 already describes the single parameter (nodeId) with 100% coverage; description adds no further meaning, meeting baseline expectation.
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 the action ('Remove a node') and the resource ('mindmap'), distinguishing it from siblings like add_idea and update_node.
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?
Explicitly advises using search_ideas first if unsure of the nodeId, providing clear guidance on when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a self-contained interactive HTML mindmap and save it to ~/.mindkeeper/mindmap-export.html. After calling this tool, tell the user to open the file in their browser — no server required. The diagram is draggable, zoomable, and uses a side-branch layout with curved connections. The toolbar inside the HTML has buttons to download the diagram as PNG or SVG.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses file path, interactivity (draggable, zoomable, side-branch layout, curved connections), toolbar features (PNG/SVG download), and that no server is needed.
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?
Four sentences that are well-structured and front-loaded. Could be slightly more concise but overall efficient.
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?
Given zero parameters and no output schema, the description provides rich behavioral details and outcome, making it very complete for an agent.
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?
There are no parameters, so the description does not need to add param info. Baseline 4 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 it generates an interactive HTML mindmap and saves it to a specific file. It distinguishes from sibling export tools by specifying 'interactive' and 'HTML' format.
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?
It explains when to use the tool (to create an interactive HTML) and includes post-use instruction (tell user to open file). However, it does not explicitly contrast with alternatives like export_json or export_mermaid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the full mindmap as raw JSON — the exact contents of mindmap.json. Use this to save a backup, import into the visualizer at the project website, or inspect the raw data structure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral disclosure burden. It transparently states that the tool exports the full mindmap unchanged ('exact contents'). Though it does not explicitly mention that it is read-only or non-destructive, the verb 'Export' implies no modification, and the description adds sufficient clarity for a simple operation.
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 consists of two efficient sentences, each providing distinct value: the first states the action and output, the second lists use cases. It is front-loaded with the core purpose and contains no wasted words.
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 zero-parameter export tool with no output schema, the description is fully complete. It names the exact file exported, explains when to use it (backup, import, inspection), and implicitly distinguishes it from sibling export tools. No additional information is needed for an agent to correctly select and invoke this 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?
The tool has zero parameters and 100% schema coverage (empty object). The description adds significant meaning beyond the schema by explaining what the output is ('raw JSON — the exact contents of mindmap.json') and offering concrete use cases, fulfilling the baseline expectation of 4 for zero-parameter tools and exceeding it with valuable context.
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 the verb 'Export', the resource 'full mindmap as raw JSON', and distinguishes itself from sibling exporters by specifying 'raw JSON' and mentioning the exact file 'mindmap.json'. It also provides concrete use cases (backup, import, inspect), making the purpose unambiguous.
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 states when to use the tool: for backup, import into visualizer, or inspecting raw data. It does not explicitly mention when not to use or compare with siblings, but the provided use cases and the context of different export formats imply appropriate usage. Clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the full mindmap as a Markdown nested list, ready to copy into a document or note. Tags are shown inline. Orphaned nodes are listed in a separate section.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers the tool's behavior: it exports the full mindmap, shows tags inline, and lists orphaned nodes separately. It implicitly indicates a read-only operation, though it does not explicitly state non-destructiveness or performance characteristics.
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 extremely concise: two sentences, no wasted words. It front-loads the main action and then adds specific details about tags and orphans, making it easy to read and parse.
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?
Given the tool's simplicity (no parameters, no output schema), the description provides complete contextual information. An agent can fully understand what the tool does, what the output looks like, and how it differs from siblings based on the description alone.
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 tool has zero parameters, so the baseline is 4. The description adds significant value beyond the input schema by detailing the output format (Markdown nested list, inline tags, orphaned nodes section), which helps agents understand the tool's output characteristics.
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 the verb 'Export', the resource 'full mindmap', and the output format 'Markdown nested list'. It distinguishes from sibling export tools by specifying the exact format and additional features like inline tags and orphaned nodes section.
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 does not explicitly state when to use this tool versus alternatives like export_html or export_json. However, the purpose is clear enough that an agent can infer it is for Markdown output. No preconditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the full mindmap as a Mermaid flowchart diagram. Paste the output into any Markdown renderer that supports Mermaid (GitHub, Notion, Obsidian) to get a visual graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It fails to disclose behavioral traits beyond the basic action, such as whether the operation is read-only, idempotent, or has any side effects. No mention of permissions or output format details.
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 extremely concise: two sentences with no superfluous text. Every word adds value, clearly explaining both the action and practical usage.
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 parameterless export tool, the description adequately covers purpose and output destination. It could mention the output is a code block or provide a usage example, but remains sufficiently complete.
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 input schema has no parameters (100% coverage trivially), so baseline score applies. The description adds no parameter-specific meaning, but none is needed.
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 the action ('Export'), the resource ('full mindmap'), and the format ('Mermaid flowchart diagram'), differentiating it from sibling export tools like export_html, export_json, etc.
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 provides context on where to use the output (Markdown renderers like GitHub, Notion, Obsidian), but does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the full mindmap as OPML (Outline Processor Markup Language). OPML is supported by dedicated mindmap apps such as MindNode, OmniOutliner, and XMind for import.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states that the export is of the 'full mindmap', implying no filtering. However, it does not disclose whether the operation is read-only, requires special permissions, or has side effects. The description is minimally adequate but lacks detail on what the agent can expect.
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 composed of two concise sentences that immediately state the action and format, then provide context about OPML and compatible apps. Every sentence adds value without unnecessary words.
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?
The description explains the output format and its compatibility, but it does not specify how the output is returned (e.g., as a file, a string, or a download URL). Since there is no output schema, the description should clarify the result structure. It is mostly adequate for a simple tool but incomplete regarding the return type.
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 input schema has zero parameters, and the description provides no additional parameter information because none is needed. Since the rubric sets a baseline of 4 for zero-parameter tools, this score reflects that the description does not need to add parameter semantics.
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 that the tool exports the full mindmap as OPML, and it lists compatible apps (MindNode, OmniOutliner, XMind). However, it does not differentiate this export from sibling tools like export_html, export_json, export_markdown, or export_mermaid, which limits clarity for selecting among them.
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 provides no guidance on when to use this tool versus alternatives. It mentions that OPML is supported by specific apps, which indirectly suggests usage for import into those apps, but does not explicitly state usage scenarios or when to choose OPML over other export formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the mindmap as a nested tree. With no arguments, returns the full tree from the root plus any orphaned nodes. Pass nodeId to get just that subtree (the node and all its descendants).
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | No | ID of a node to get its subtree. Omit to retrieve the entire mindmap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior: returns nested tree, includes orphaned nodes, subtree limiting. However, it lacks details on authentication, rate limits, or response structure, which would be expected given no annotations.
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?
Two concise sentences that immediately convey the tool's purpose and usage variants. No redundant information.
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?
The description is sufficient for a simple read tool but lacks details about the return format (e.g., JSON structure) which would be expected without an output schema. It could also mention performance or limits.
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 parameter nodeId is well-described in the schema (100% coverage). The description adds context about 'orphaned nodes' but does not provide significant new semantics beyond the schema.
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 the verb 'Retrieve' and the resource 'mindmap as a nested tree'. It distinguishes between two use cases (full tree vs subtree) and differentiates it from sibling export tools.
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 explains when to use each variant (no arguments vs nodeId). However, it does not explicitly mention when not to use it or compare to alternatives like export_*, leaving some ambiguity in multi-tool scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a conversations.json file exported from Claude.ai and return a structured list of conversations. The user must first download their data at claude.ai → Settings → Account → Export Data, unzip the archive, and provide the path to conversations.json. After calling this tool, YOU (the AI) must analyze the returned conversation list and: 1) identify major topic clusters across the conversations, 2) call add_idea to create a root topic node for each cluster, 3) call add_idea to add notable sub-topics or recurring themes as children, 4) skip trivial, one-off, or very short conversations. Group by theme, not by conversation title. Aim for a clean, meaningful mindmap hierarchy. When done, call export_html so the user can visualize the result.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the conversations.json file from the Claude.ai data export. Windows example: C:\Users\name\Downloads\conversations.json. Mac/Linux example: /Users/name/Downloads/conversations.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains input (file path), prerequisite (download/untar), and output (structured list). Does not mention any side effects or permissions, but as a read operation, this is adequate.
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?
Description is relatively long but well-structured, front-loading the core action and then providing usage steps. Every sentence adds value, though some could be consolidated. Still, it's efficient for the complexity.
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?
Given no output schema, the description explains the return value type. It also provides a complete workflow for the AI after tool use, covering analysis and follow-up tool calls. Highly complete for the intended use case.
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?
Only one parameter 'filePath' with schema coverage 100%. Description adds workflow context about how to obtain the file, which helps the AI guide the user. Baseline 3 is elevated because the description enriches understanding beyond the schema.
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?
Description clearly states 'Read a conversations.json file... and return a structured list of conversations.' Specifies the exact file and output format, distinguishing it from sibling tools like add_idea or export_html.
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?
Explicitly instructs on prerequisites (user must download data from Claude.ai), step-by-step usage, and post-call actions for the AI, including how to organize results. Leaves no ambiguity about when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the mindmap for nodes matching a query string. Scores nodes by exact match > substring > per-token matches in text and tags. Use this to find a node ID before updating/deleting, or to surface related ideas.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms — partial words and phrases both work |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency burden. It discloses the scoring mechanism (exact match > substring > per-token matches), which is helpful. It implies read-only operation, but could explicitly state that it does not modify data.
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 sentences long with no superfluous words. The first sentence covers functionality and scoring, the second provides use cases. Every word earns its place.
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?
Given the tool's simplicity (1 parameter, no output schema), the description is nearly complete. It lacks details about the return format (e.g., list of node IDs or full node objects), which would be helpful for an agent. However, the essential information for selection and invocation is present.
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?
With 100% schema description coverage for the single query parameter, the description adds value by explaining how the query is matched, beyond the schema's 'partial words and phrases both work'. This additional context justifies a score above baseline 3.
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 the tool searches the mindmap for nodes matching a query string, and details the scoring hierarchy. It distinguishes itself from sibling tools like export or add operations by being the only search 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 explicitly recommends using this tool to find a node ID before updating/deleting or to surface related ideas, providing clear usage context. It does not mention when not to use it, but given no sibling search tool exists, that's acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync the mindmap with GitHub Gist cloud storage. Requires ~/.mindkeeper/config.json with cloud credentials (see README). Use direction='push' to upload local state, 'pull' to download and overwrite local. First push auto-creates a private Gist and saves the gistId back to config.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | push = upload local → cloud | pull = download cloud → local |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: direction options, credential requirement, first push auto-creates Gist and saves gistId. No annotation burden, but could mention error handling.
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 concise sentences, front-loaded with purpose, no wasted words.
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?
Explains process well but lacks output/return value description. No output schema, so description should cover this gap. Adequate for low 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 100% with clear enum descriptions. Description adds first-push context but no new param info beyond schema.
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?
Clearly states 'Sync the mindmap with GitHub Gist cloud storage' – specific verb+resource. Differentiates from siblings like cloud_status, export_*, etc.
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?
Explains when to use push vs pull and prerequisite config file. No explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit the text or tags of an existing node. Use this when an idea has been refined, clarified, or its scope has changed. Does not change parent/child relationships — use add_idea + delete_node to restructure.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the node to update | |
| newText | Yes | Replacement text for the node | |
| newTags | No | Replacement tag list (full set — overwrites existing tags). Leading # is stripped and values are lowercased automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that newTags overwrites existing tags with auto-stripping of # and lowercasing, and confirms no effect on parent/child relationships. However, it omits side effects like cloud sync triggers or reversibility, leaving minor gaps.
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, no wasted words. The action is front-loaded, and every sentence adds value: first states purpose, second gives usage context, third clarifies scope and notes alternatives.
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?
Covers key aspects: what it does, when to use, and behavioral details like tag handling. However, it lacks information about the return value (since no output schema), which is a minor gap for a tool that updates existing data.
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 descriptions for all three parameters are already detailed (100% coverage). The description adds context by linking parameters to use cases ('Edit the text or tags'), but does not significantly enhance beyond what the schema provides. 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 clearly states 'Edit the text or tags of an existing node', specifying the verb ('edit') and the resource ('node'). It distinguishes from siblings by noting that it does not change parent/child relationships and directs to use add_idea + delete_node for restructuring.
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?
Explicitly states when to use: 'when an idea has been refined, clarified, or its scope has changed.' Also provides alternative actions for cases where parent/child relationships need to change, giving clear when-not-to-use guidance.
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.
v1.5.2add_ideacloud_statusdelete_nodeexport_htmlexport_jsonexport_markdownexport_mermaidexport_opmlget_mindmapimport_claude_exportsearch_ideassync_cloudupdate_nodeEach tool has a clearly distinct purpose: adding, updating, deleting, searching, retrieving, exporting in various formats, cloud sync, and import. There is no overlap or ambiguity between any of the tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_idea, delete_node, export_html). No mixing of conventions or confusing abbreviations.
13 tools is well-scoped for a mindmap server. They cover CRUD operations, multiple export formats, cloud sync, and an import feature, without being excessive or sparse.
The toolset covers most core operations (CRUD, search, export, sync). A minor gap is the lack of a direct move/reparent operation, requiring workarounds (delete + add). Otherwise, the surface is comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Voice notes that organize themselves. Capture by Siri, AI auto-tags, semantic search retrieves.
Brain dump, routines, task planning, focus, and instant thought retrieval
A self-improving memory layer. Your memory, notes, tasks and goals, remembered everywhere.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/icedsg/mindkeeper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
