Your mind maps, as tools for AI agents

Requirements

• A miMind Business or miMind AI subscription, signed in to your miMind account. The server uses none of your AI allowance: your agent’s own AI does the thinking.
• The miMind desktop or mobile app: the MCP Server dialog lives there (the web app has none). With miMind Business, use miMind 26.10.31 or later; earlier versions open the dialog for miMind AI subscribers only.

Steps

1. Open the main menu → Settings → AI Settings and pick MCP Server… (available from both the map list and an open map).
2. Turn on Sync my maps to the MCP server. Nothing is published before you do. From then on, each map you save publishes an outline copy that agents read; from miMind 26.11.6, opening a map publishes it too, and the switch is remembered for each account you sign in with.
3. Press Generate New Token and copy the token — it is shown exactly once (miMind stores only a hash). From miMind 26.11.6 you choose first: Can read and change maps, or Can only read maps for a token that only reads (see Read only). You can keep up to 5 active tokens and revoke any of them at any time.
4. Copy the Server URL from the same dialog and configure your MCP client with both (see Client Recipes).

A client that signs in (claude.ai, Claude Desktop’s connectors, ChatGPT, Claude Code) needs no token: skip steps 3 and 4 and see Signing in. Step 2 still matters: agents read only the maps your app has published.

What agents can see

• A text outline of each published map: its title, and each node’s title and note, in tree order. Titles and notes are each cut to 160 characters, the outline holds up to 800 nodes (a bigger map’s outline ends with … (map truncated for length)), and it is at most 256 KB.
• A full copy, from miMind 26.11.6: with the outline, the updated app publishes a fuller copy of each map, up to 2,000 nodes: each node’s whole title (up to 1,000 characters) and note (up to 4,000), its fill, text and border colours, shape, bold and italic, whether it is collapsed, its date, and up to 20 items of its content — text, check boxes with their labels and whether they are ticked, links with their web address, an image’s caption with its web address, a table’s size, and only the kind of anything else; the cross-links between nodes with their labels; and the map’s theme, layout, scene and background colour. It holds a web address only when it starts with http:// or https://: never a file path on your device, and never an attachment, an image or a file itself. A map an earlier version published has the outline alone, and the tools say so.
• Tables, lists and a picture, once switched on: from miMind 26.11.6, the full copy can also hold the cells of tables, the items of lists, chart titles, calendar cards’ titles and times, which of your maps a map links to, and the size and type of pictures, videos, sounds and attachments — never a file, a file name or anything about places — and a small picture of the map as you last closed it (see Rich content and Map pictures).
• Items inside notes, once switched on: from the next miMind update, the full copy can also list what sits inside a node’s note (up to 20 items) and inside its text items (up to 10 each) — their text, check boxes, links and the web addresses of pictures and media with their captions, tables, lists, charts, calendar cards’ titles and times, which of your maps a note links to, and the kind and size of pictures and files, never a file name or anything about places — for get_inner_content. A version saved in Version History while this is on keeps them with that version, and they are deleted with the version.
• A word list, once switched on: our server keeps, with each map’s copy, a list of the words in it, in a simplified form that ignores capitals, accents and word endings, so that find_in_maps can find maps by their words (see Word search). It is made from the copy itself, never shown as such, and deleted with the copy.
• Node ids, from miMind 26.11.6: the updated app gives each node a hidden id the first time it saves the map with sync on, and keeps it in the map file, so an agent can find the same node again after the map changes (see Ids). Opening a map does not add them, and an earlier version drops them when it saves the map.
• Where each map’s file is, once file places are switched on: from miMind 26.11.6, the drive, the folder and the file name of each map it publishes with sync on, for list_files and the file tools; never the full path on your device (see Security & Privacy).
• As last saved. Agents read the copy, not the map: edits you have not saved yet are not in it, and a map you have never saved (or, from miMind 26.11.6, opened) with sync on is not listed.
• Maps shared with you are published like your own when you save them with sync on. Agents can read them but never change them. From miMind 26.11.6, agents can also see who is in a shared map your app published, and read its saved versions (see Maps shared with you and Version history).
• Encrypted maps: from miMind 26.11.6 they are never published. The updated desktop or mobile app removes a copy already published for one when you encrypt that map there, when you open or save it there with sync on, and once, with sync on, for the encrypted maps in its own maps folder (up to 2,000 map files). A map encrypted in the web app, or one an earlier version published from elsewhere (such as a cloud-storage folder), keeps its copy until an updated desktop or mobile app opens it with sync on, or you turn sync off and choose Remove. A map you decrypt in the desktop or mobile app is published again on its next open or save; one decrypted in the web app stays unpublished until you turn Visible to MCP Agents off and on again. Earlier versions publish an encrypted map like any other (the server cannot tell them apart), so update miMind, or keep sync off, before you sync encrypted maps.
• Taking copies away: from miMind 26.11.6, deleting a map in the desktop or mobile app removes its copy when you delete it from a cloud-storage list, or when that device has published it since the update (it opened or saved the map with sync on) and it was not renamed or moved since; a copy of the map that kept its id keeps the copy. Otherwise a copy may stay until you choose Remove: for example that of a map deleted in the web app or outside miMind, or one an earlier version published that the update has not opened since. Turning sync off asks whether to Remove every copy or Keep them. Sync is set on each device: turn it off on every device where it is on, or the others publish their maps again as you open or save them. In the open map’s Settings menu (shown while sync is on, for a map that is not encrypted), Visible to MCP Agents hides that one map. From miMind 26.11.6, the owner of a map shared with others finds the switch in the map’s menu and in its Share panel, with sync on or off, and turning it off there hides the map from every member’s agents too (see Maps shared with you). The app makes these removals only while you are signed in on a plan that includes MCP. Earlier versions leave copies on the server after a delete or after sync is turned off. Revoking your tokens and disconnecting your connected apps stops every agent at once, and when your miMind account is deleted, so is every copy.

Maps shared with you

From miMind 26.11.6, an agent can read more of the maps you share with other people, and of those others share with you: which they are, the people in each, the map’s conversation, its recent changes and its saved versions. Only maps your own app published: opening or saving a shared map with Sync my maps to the MCP server on is what lets your agent see it — list_shared_maps only counts the others — and nothing of a map its owner hid from agents.

• What it sees of other people — their display names (never an email address: a name that looks like one shows as a member, or the owner for the owner), their roles, how many people a map has, whether someone has it open now, and the days (UTC) each was last there and last edited it; and who saved the map last and each of its versions, and when (exact times, as their apps recorded them). Never where in the map they are, their device, their picture, their email address or their account id. People who left the map show as a former member, and their messages are listed without their words.
• The conversation and the changes — the messages of the people in the map (each cut at 500 characters, newest first), and which nodes and links changed or were removed in the last 30 days at most, with who changed each last and when by that person’s device clock: both are switched on separately (see below).
• As their apps recorded it — who saved, changed or wrote something is what each person’s app recorded; it is not verified, and the tools say so (authors_unverified).
• Other people’s words are data — names, titles, messages and version summaries written by others are shown as text to read, never as instructions to follow; the tools say so to the agent.
• Read only — inviting people, removing them, changing roles, stopping sharing and writing in the conversation stay in miMind. A map someone else shared with you stays read-only to agents, as before.
• The owner’s switch — the owner of a shared map, signed in with a verified email, can keep it away from every member’s agent: turn off Visible to MCP Agents in the map’s menu or its Share panel (in the desktop and mobile apps, not yet the web app), with sync on or off and with or without a plan that includes MCP. The copies members’ apps published are deleted, new ones are not kept, and every tool answers as if the map were not there. It does not reach copies members saved as their own files. Your app keeps asking our server until it has taken the change, for up to 30 days, so a change made while the server could not take it yet still reaches members. The switch shows what you last set on this device: without MCP, a change made on another of your devices does not show here, so this device can still show the map as hidden after you made it visible again elsewhere, or the other way round. Set it again here to be sure: turning it off again is harmless. Turned back on, a member’s agent sees the map again after that member’s next save with sync on, an hour later or after their app restarts (with an earlier version, after their next edit). A map you hid from your own agents before this update is, from then on, hidden from your members’ agents too. Members cannot keep themselves out of what their co-members’ agents see; only the owner’s switch hides a map.

Version history

On plans that include it, miMind’s Version History keeps saved versions of a map. From miMind 26.11.6 an agent can list them (list_map_versions), read one (read_map_version) and ask you to restore one (propose_restore_version). For a map someone else shares with you, your agent reads the owner’s version history, as the app shows it to you.

• What can be read — every version is listed with when it was saved, who saved it (as the app recorded it), its summary of changes (in the saving device’s language) and its size. A version saved by miMind 26.11.6 or later while the map was published with sync on also holds the copy agents read, so read_map_version can read it as read_map reads the current copy; older versions, those saved with sync off, of a hidden or encrypted map, or of a very large map, show their summary only. A version can hold what people later deleted from the map, as Version History in the app shows it.
• How fresh — versions go up about every 10 minutes of editing; minor versions are thinned within a day, major ones kept longer.
• Restoring — only through a request you approve in the map’s Agent Requests, with the map open. The app first keeps the current map as a version (Before restoring the version from …), then replaces the map’s nodes and its look (canvas colour, wash, theme, scene, line flow, glow, grid) with the version’s; Undo brings the nodes back, not the look, and the kept version has both (from the next miMind update, Undo brings the look back too). Refused for a map you share with others (restore it yourself from Version History) and for maps others share with you (see Restoring a version).

Rich content: tables, lists, charts, cards and links

From miMind 26.11.6, once our server takes it, the full copy of each map your app publishes with sync on also holds more of what its nodes show, for get_node_content, get_map_links, export_events, export_map’s web page and the table tools. The tools you knew before read the copy exactly as they did.

• Tables — the title, the column and row headers and the cells, up to 100 rows, 20 columns and 2,000 cells a table, each cell up to 200 characters (in a large map fewer: 20 rows a table, 60 characters a cell; a cell cut short ends in …, and the tools say so with cells_cut). A table in a note, and the table inside a Gantt chart, are not content items.
• Lists, charts and calendar cards — a list’s title and up to 50 of its items; a chart’s type (pie, bar, line or Gantt) and title, not its data; a calendar card’s title and its start and end, in UTC (never its id in your device’s calendar).
• Links between maps — which of your maps a map-link card or a miMind link opens, by its map_id, and the card’s title only when that map is one agents can read. A map you hid from agents, did not publish or whose owner hid it is never named: the tools only count such links.
• Media — the pixel size and the type (the file’s extension) of pictures, videos, sounds and attachments. Never a file, its bytes, its name or a path on your device.
• Nothing about places — a place card shows only that there is one: no address, no place name, no coordinates.
• Only when it fits — the app adds this only while the map’s copy is whole or only lightly shortened (notes up to 1,000 characters), as in a small or medium map, and never makes the rest of the copy smaller to make room; a copy published by an earlier version, or before this was switched on, has none of it, and the tools say so (no_rich_content).
• Other people’s words — in a shared map, cells and list items may be written by others: the tools tell the agent to treat them as data, not as instructions.

Map pictures

From miMind 26.11.6, once our server takes them, your app publishes a small picture of each map with its copy, and get_map_thumbnail shows it to the agent (an image its AI service receives). It is the picture miMind makes when you close a map or save it from its menu, at most 256 pixels on its longer side and 48 KiB, re-encoded without any of the file’s metadata.

• Only a fresh one — the app sends the picture only with the copy it publishes after such a save (or when you turn Visible to MCP Agents back on), while the map is unchanged since that save and its picture is not older than its content. Opening a map never sends one, and a map you reopen unchanged is not published again, so its picture stays. Once you change the map, the next copy goes without a picture, and the stored one is deleted, until you close the map again: a picture never shows what you have changed or removed since. An autosave, a change an agent made, and a device with an earlier version publishing the map also leave it without one until the next close; so do maps that take long to save, and the Windows Store app; a copy a request_map_copies run published may have none until you next close the map.
• What it shows — the map’s look and, at low resolution, the pictures in it, its place cards (a map tile with a pin) and its link cards, including a card that opens a map you hid from agents.
• Where it goes — it is kept inside the map’s copy on our server and deleted with it (see Security & Privacy).

Word search

From the next miMind update, once our server keeps word lists, find_in_maps finds your maps by the words in them and puts the best first, each with the lines that matched. It is word search, not semantic search: no AI model reads your maps or the question, nothing is turned into embeddings or vectors, and the question is never stored. It finds a map when the map holds one of the words asked, in some form — it does not know that two different words mean the same thing, so an agent adds synonyms, related words and translations itself (the tool’s any), and words every map must hold (all).

• What a word matches — capitals and accents are ignored (cafe finds Café, istanbul finds İstanbul, strasse finds Straße), and so are common word endings in the 16 languages with a standard stemmer — English, German, Spanish, French, Portuguese, Italian, Swedish, Norwegian, Turkish, Hungarian, Danish, Dutch, Romanian, Russian, Arabic and Hindi (plans finds planning). Chinese, Japanese, Thai and Korean text is split into words, and Chinese and Japanese also into pairs of characters. Vietnamese tone marks are ignored, so ma finds each of its toned spellings. Small typos are forgiven when fewer than 3 maps match exactly: one letter off in a word of 4 to 7 letters, two from 8, with the same first letter, among your 200 most recently updated maps (typo_pass).
• The word list — made by our server, while the copy is published, from the map’s title, its nodes’ titles and notes, text items, check boxes, link cards’ labels, the captions of pictures and media, chart titles, table titles, headers and cells, and list titles and items: never web addresses, file names, colours or ids. At most 500 entries; the title’s words count most, then the nodes’ titles. The endings are taken off only for the (at most two) languages the map is found to be written in, which needs a few common words of that language, so a very short map (“Budget planning 2027”) gets none, and plans does not find it. A very large map, or one whose text takes too long to sort, keeps the words of its title and outline only. If we switch word search off again, new copies are kept without a word list, and a clean-up we run deletes the lists already stored.
• Maps published before — a map whose copy has no word list yet (published before word search, or too large for one) is found only by its title, when typos are looked for, and counted as such (index_partial); search_maps still finds any text in it. The next copy your app publishes of it (when you save it with sync on) has one, and when we switch word search on we fill in the lists of the copies published before, once.
• Limits — one search asks for at most 30 word forms (words_cut) and ranks the first 500 maps that hold one (candidates_cut: add words to narrow it); it shows up to 25 maps, 3 lines each, and with scope full the notes and text items of the first 10. A call counts as 10 requests.
• search_maps and ChatGPT’s search — once switched on, search_maps also ignores capitals and accents (it still finds one run of text, never words apart), and a ChatGPT connection’s search lists the maps word search ranks first (without the typo pass), then those search_maps finds.

Agent drawings

From the next miMind update, add_drawing lets an agent add a drawing to a node from SVG it writes: a diagram, an icon, a simple chart. SVG is a language that can do much more than draw, so the drawing goes through two checks and reaches every app as a plain picture.

• Our server keeps only drawing — shapes, groups, text, gradients, patterns, clip paths, masks, markers, symbols and references inside the same SVG. It refuses scripts, styles, embedded or linked images, foreign objects, links, animation, filters, DOCTYPE and entities, and any reference outside the SVG (a web address, a file, data:); it never opens an address. It leaves out what it does not keep and drops very fine dash patterns (svg_dropped), reduces very wide strokes, huge text and oversized boxes (svg_clamped), refuses deep transparency, extreme transforms and a drawing with too much to draw, and queues its own clean copy, never the agent’s text: at most 64 KiB, 4,000 elements and 32 levels.
• Your app checks it again and makes a picture — the next miMind update checks the drawing against the same rules, draws it in the background with miMind’s hardened SVG renderer into a PNG picture of at most 1,024 pixels on its longer side (768, then 512, when it would pass 1 MiB), and adds that picture to the node, keeping the clean SVG beside it in the map. A drawing the renderer cannot finish is refused (svg_too_complex); one it could not draw for lack of memory waits for a later try (at most 3 on a device).
• Safe on every installed app — earlier miMind versions, the people you share the map with and file viewers only ever see the picture: none of them reads an agent’s SVG. This is said of add_drawing only: a picture address ending in .svg given to add_content is still drawn by each app with its own SVG renderer, so keep miMind up to date.
• Text — text in a drawing draws only where the device has the fonts it needs (svg_text): paths draw everywhere.
• Limits — at most 50 drawings a day (UTC) for your account. The map shows and exports the picture; an agent cannot read a drawing back.

What every client needs

• Server URL: https://us-central1-mimind-ebda5.cloudfunctions.net/mcp, or, once signing in is switched on, https://mimind.app/mcp, the same server at miMind’s own address (the one to give a client that signs in).
• Auth: either the header Authorization: Bearer mmcp_YOUR_TOKEN, with the token from the MCP Server dialog, or, for a client that signs in, nothing: it opens miMind’s sign-in page and keeps its own token (see Signing in).
• Transport: MCP Streamable HTTP, stateless.

Treat the token like a password: keep it out of files you commit or share, and revoke it in the MCP Server dialog, or on Manage Account, if it leaks.

Sixty-two tools

Three list, read and search the published copies; three queue a new map, new nodes or a scene for your miMind app to make; three follow up on those queued requests; three queue edits to nodes already in a map: new nodes at an exact place with their formatting, renames and new formatting, and moves. Then three more read the copies in depth — one node in full, what a map is made of, and the tasks and dates across your maps — and two read no map: the names the tools accept, and which account and devices the connection reaches. Then one queues content for nodes a map already has: text, links, pictures, videos, check boxes, lists, tables, charts, places, calendar cards and emoji, and text at the end of a note. Then a pair queue a new look for a map (its layouts and their dials, themes, canvas, and where the central topics sit) and new central topics, each a tree of its own; then one queues new cross-links between nodes and changes to the look of the lines: labels, colours, patterns, widths, types and end shapes, hiding and showing, and animations; then four queue formatting (fonts, emphasis, words inside a title, shapes, sizes, numbering, grouping and the look of notes), ticked check boxes, folded branches and a focused node, copies of branches, and refinements of a map’s style (the spacing of sub-nodes, the style sheet’s defaults or the theme’s styling, the glow and the flowing lines). Then four only ask: three propose deleting parts of a map, replacing its notes, a line’s animations or the text of an item, adding items to a check-box group, or taking back what an earlier request added, and wait for your approval in miMind; one leaves you a message. Then ten work with files and folders, from miMind 26.11.6: one asks you to approve moving a map to the trash; one lists where your maps’ files are, and what is in the trash; seven queue file work for a device that has the file — a new map built from topics, text or a template, a renamed, moved or copied map file, a new or renamed folder, and a map brought back from the trash; and one queues a link from a node to another map. Then seven, from miMind 26.11.6, read sharing and version history: four read the maps shared with you or that you share — which ones, the people in each, its conversation and its recent changes — two list and read a map’s saved versions, and one asks you to approve restoring one. Then nine, from miMind 26.11.6, export and read in depth: two export a map’s copy as FreeMind, a web page, a JSON tree or CSV, and the dates of your maps as a calendar; three read a node’s tables, lists and other content, the links between your maps, and a small picture of a map; one fills empty table cells and adds rows and columns, and one asks you to approve changing a table; and two ask your miMind app to save an export as a file on your device, and to publish the copies agents read of maps that have none yet. The last seven, from the next miMind update, find and add: one finds your maps by their words and ranks them (word search, not semantic search: see Word search); one reads what sits inside a node’s note and its text items; and five queue additions and small rearrangements — items at the end of a node’s note, a drawing made from SVG (see Agent drawings), a content item moved to another place in its node, a saved or new scene behind the map, and a node’s title turned into a short list. Read-only tools never change anything; the write tools never change a map themselves (see How Writes Work), the direct ones delete nothing and replace no note or item text (a new look keeps every node’s text, note and content), and a deletion or replacement happens only when you approve it in miMind (see Agent Requests). No tool deletes a file or a folder: a map leaves only through the trash, when you approve it, and nothing is ever written over a file or folder that is there. No agent changes or clears a table cell that has text, retitles a table or removes a row or a column without your approval: edit_table only fills empty cells and headers and adds rows and columns.

Read only. A token made with Can only read maps (from miMind 26.11.6), or an app connected with changes not allowed, lists only the read-only tools: list_maps, read_map, search_maps, get_command_status, list_commands, get_node, get_map_info, read_tasks, list_catalog, get_sync_status, list_files, list_shared_maps, get_map_members, read_map_chat, list_map_changes, list_map_versions, read_map_version, export_map, export_events, get_node_content, get_map_links, get_map_thumbnail, find_in_maps and get_inner_content (and, on a ChatGPT connection, search and fetch, and, where the chat draws views, show_map). It can list, read and search your maps but never queues a change: a write tool called anyway is refused, with a tool error for a token and HTTP 403 insufficient_scope for a connected app (see Protocol Details). To let it change maps, make a new token, or connect the app again and allow changes.

Limits

Limits for your account. Besides the limits of each token and connected app above, we may hold all of your account’s requests together — from every token and connected app — to limits that depend on your plan, counted in each of our server’s instances (and, where a plan has a daily limit, for the whole day on our server). Once we switch them on, every request counts toward them: a tool call as above; a tool that reads long lists, one more for every so many documents it reads — list_maps, search_maps, read_tasks, get_sync_status, list_files, rename_folder, list_shared_maps, read_map_chat, list_map_changes, search, export_events, get_map_links, get_node_content, show_map, list_commands, find_in_maps and get_command_status; and any other request, such as tools/list, by the size of its answer. When your account reaches one, a tool call answers Account rate limit reached (…). Try again in … s. and does nothing, and any other request gets HTTP 429 with Retry-After. If our server cannot check a daily limit, the call is refused rather than run: Could not check today's account limit. Try again in 5 s. Nothing was run.

list_maps read-only

Lists your published maps, most recently updated first: id, title, node count, and when each was last updated. Up to 100 a call; when there are more, the reply ends with a cursor for the next page.

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "list_maps", "arguments": {} } }

Returns one line per map, e.g. - map_id: id_1730450000_9f2c… | "Product Roadmap" | 42 nodes | updated 2026-10-24T09:12:03.000Z, then (More maps: call list_maps with cursor "…".) when there are more. With nothing published yet it says how to turn on sync.

With details, each line goes on with the publisher, the kind of copy and, when the map has more nodes than its outline holds, its node total: … | miMind 26.11.3 (iOS) | full copy | 1500 nodes in the map. A copy an earlier version published says older app and text outline only, and cut when it misses nodes. A map published before the server kept this, or while it is switched off, ends | publisher unknown.

Structured result: maps[] (map_id, title, node_count, updated; with details also published_by {app, version, platform}, source (detail or outline), truncated and nodes_total) and next_cursor.

read_map read-only

Returns a map’s outline as indented text: one node per line, children indented two spaces under their parent. A long outline comes in pages of whole lines. It can also return one branch, a few levels, or the map in another format (Formats, branches and depth).

{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "read_map", "arguments": { "map_id": "id_1730450000_9f2c" } } }

The reply, line by line:

Map "Product Roadmap" (map_id: id_1730450000_9f2c, 6 nodes)

e0 Product Roadmap
  e1 Q3
    e2 Launch beta  — invite 50 customers first
    e3 Pricing page
  e4 Risks
    e5 Key-person dependency

• eN labels are positions, not ids. They number the nodes in tree order, from e0, the first central topic, through every root of the map; they change whenever the map changes. To name a node exactly, even one whose title others share, pass its label together with this read’s revision to insert_nodes, update_nodes, move_nodes or add_nodes (parent_eid): they refuse a revision once the map has been saved again (see Editing nodes). Otherwise name a node by its title.
• Ids last; labels do not. From miMind 26.11.6 each node also carries an id, such as n3k9x0ab, that stays the same when the map changes: the json format, get_node and a full search show it. Name a node by it as id:n3k9x0ab in read_map’s node and in get_node. A node gets its id the first time the updated app saves the map with sync on; a copied node gets a new one; an earlier version drops the ids when it saves the map, and the next save by the update gives new ones. An id the copy no longer has is refused (No node with id "…" in the copy of "…".), never taken for another node. From miMind 26.11.6 the edit tools and add_content take them too, as id:n3k9x0ab wherever they take a node (see Naming a node), and get_command_status gives the ids of the nodes a request created (created_nodes), to use once the app has published the map again.
• A node’s note follows its title after two spaces, an em dash and a space ( — ). Titles and notes are each cut to 160 characters (ending in …).
• A map with more than 800 nodes is cut, and its copy ends with … (map truncated for length).
• A page that does not reach the end finishes with … (lines 1-2400 of 5200; call read_map with offset=2400 to continue). The pages, joined with a line break, are the outline exactly.

Structured result: map_id, title, node_count, updated, outline (this page’s lines), first_line, next_offset (absent on the last page), total_lines, truncated (true when the server cut the copy to fit 256 KB; a copy the app cut at 800 nodes says so only in its last line, … (map truncated for length)) and revision: a fingerprint of the copy this read shows, the same on every page, which the edit tools take with eN labels. The text reply does not show it, so a client without structured output passes labels without a revision (they are then checked against the current copy, with the warning revision_assumed) or names nodes by title.

Formats, branches and depth

Without format, node and depth (or with format outline alone), read_map answers exactly as above.

• A branch of the outline: node and depth with the default format give the same lines, two spaces per level below the start, under a second head line: Branch e12 "Budget" (34 nodes, depth ≤ 2). Pages are lines of the branch, and offset counts within it. The outline holds the first 800 nodes, so a label past them is refused there (… is past the end of the text outline (it holds the first 800 nodes); ask for format "json".).
• The other formats come from the map’s full copy, or from the outline when the map has none (the head line says which: full copy or text outline only). They give the whole selection in tree order, in pages of whole nodes: offset is the node to start at, and a page that does not reach the end finishes with … (nodes 1-400 of 1500; call read_map with format=json, offset=400 to continue).
• json: one JSON object per line, each node as get_node describes it (eid, id, parent, depth, title, note, children, collapsed, date, layout, style, content); the last page adds a line {"link":{"from":"e3","to":"e40","label":"…"}} for each cross-link inside the selection.
• markdown: # Title, then a bulleted list, two spaces per level; notes and content one level deeper, check boxes as - [ ] and - [x], links and web images as [text](url).
• opml: an OPML 2.0 document, each node an <outline text="…" _note="…">; every page is a whole document.
• csv: one row per node, eid,id,level,parent,title,note,date,tasks_open,tasks_done, with the header on the first page only.
• plain: the titles indented two spaces per level, each with its note after — , without labels.

{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "read_map", "arguments": {
    "map_id": "id_1730450000_9f2c", "format": "json", "node": "e1", "depth": 1,
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418"
  } } }

Map "Product Roadmap" (map_id: id_1730450000_9f2c, 6 nodes) — json, full copy, branch e1 "Q3", depth ≤ 1

{"eid":"e1","id":"n0k2m9qa","parent":"e0","depth":1,"title":"Q3","children":2,"style":{"fill":"#336699","bold":true}}
{"eid":"e2","id":"n7c1x4rb","parent":"e1","depth":2,"title":"Launch beta","note":"invite 50 customers first","children":0,"date":"2026-09-15","content":[{"kind":"check","text":"Invite list ready","checked":true}]}
{"eid":"e3","id":"n5t8w2pe","parent":"e1","depth":2,"title":"Pricing page","children":0,"content":[{"kind":"link","text":"Draft","url":"https://example.com/pricing"}]}

{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "read_map", "arguments": { "map_id": "id_1730450000_9f2c", "format": "markdown" } } }

Map "Product Roadmap" (map_id: id_1730450000_9f2c, 6 nodes) — markdown, full copy

# Product Roadmap

- Product Roadmap
  - Q3
    - Launch beta
      - invite 50 customers first
      - [x] Invite list ready
    - Pricing page
      - [Draft](https://example.com/pricing)
  - Risks
    - Key-person dependency

Structured result in these formats: outline is empty, first_line is the offset, total_lines is the number of nodes in the selection, and truncated is true when the copy misses nodes; with format, source (detail or outline), revision, updated, next_offset and subtree (eid, id, title of the branch). json adds nodes[] and links[]; the exports add content (the export itself), mime_type and filename (the map’s title, with an extension), so a client can save it as a file. A branch of the outline keeps the outline’s fields, with subtree.

search_maps read-only

Case-insensitive text search across your published maps (titles and node text). Returns each matching map with its matching lines. It searches up to 200 maps a call, most recently updated first; when older maps remain, the reply ends with a cursor that searches them.

{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": { "name": "search_maps", "arguments": { "query": "budget" } } }

Returns Maps matching "budget":, then - map_id: … | "Title" for each map with its matching lines (and (title match)) indented under it, or No maps matched "budget" (searched N maps). A reply stops at a whole map once it reaches about 45,000 characters, with a cursor for the rest.

With scope full it searches every node’s whole title, note and content (the text of items, link and image addresses) in maps that have a full copy, 100 maps a call; each matching line reads e12 Budget — …about 160 characters around the hit…. Maps an earlier version published are searched as before and counted, and the reply ends by saying how many there were (their notes were searched as cut, their content not at all).

Structured result: query, scanned, results[] (map_id, title, title_match, lines; with full also hits[]: eid, id, where (title, note or content) and snippet) and next_cursor; with full also scope and outline_only (how many maps had the outline alone).

create_map write

Queues a new miMind map built from an indented text outline. Your miMind app builds it the next time it starts, or you sign in, on a device with Sync my maps to the MCP server on (from miMind 26.11.6, also as soon as your plan becomes active). It then appears in your map list like any other map, and in list_maps once it is published.

How the outline is read

• The title is the central topic, and the outline’s top-level lines are its branches. An outline whose only top-level line repeats the title (Trip to Japan with everything indented under it) is read the same way: that line becomes the central topic itself, never a second one.
• Any consistent indentation: two spaces, four spaces or tabs per level. The outline is tidied before it is queued: indentation that skips a level is fixed; bullets (-, *, • and the like) and task boxes ([ ], [x]) are removed; list numbers (1., 2), 1.2) are removed only when every sibling carries one, so 2026 plan keeps its year; and read_map’s eN labels are removed when at least half of the lines carry one. The reply says what was tidied (The outline was tidied: …).
• Notes: text after — on a line is that node’s note, never part of its title. From miMind 26.11.6 the note is written into the node; older versions leave it out. The reply counts them (… note(s) after " — " kept as notes (an updated app writes them)), and warns notes_not_written when none of your recent devices can write them.
• An outline with nothing left after tidying, or over 256 KB, is refused.

The new map’s id

The reply starts Queued (command <id>). and then either says Its map_id will be <id>. — when this account’s miMind has synced in the last 30 days and every device that did runs miMind 26.11.6 or later, which builds the map under that id and publishes it right away (should the device that picks the request up stop before building it, the one that builds it instead gives the map a new id) — or that the id is not known until the map is opened and saved in miMind. Either way, get_command_status reports the id once it is known.

On older versions of the app

miMind 26.9.23 and older build the map without its layout or background. 26.10.22 to 26.10.24 build both, except a scene marked (miMind 26.10.30+), which is left off; a 26.10.30 build may leave it off as well. Every version up to 26.10.31 builds the map without its theme (in the default look) and without its notes; miMind 26.11.6 writes both. When none of your recent devices can show what you asked for, the request still queues and the reply adds a Note: (see Notes and warnings).

The 64 scene ids, in the 10 groups of the style sheet. Scenes are gentle by design — sparse, slow and calm in the middle of the screen, expressive on a dark theme and painted as daylight on a light one (the auroras and the Wind & Wave silks are vivid on a dark theme) — so the map stays readable on top, and their colours follow the map’s theme. Most move gently, many in depth; those marked (still) do not move. Those marked (miMind 26.10.30+) need that version or later (26.10.31 to be sure; see App Versions): an older app builds a new map without them, and a set_background waits for an updated app. Only the ids listed here can be set; a map that already shows another scene keeps it.

Designing a new scene with AI (Generate with AI in the style sheet) is an in-app feature and is not offered over MCP; see the AI Guide.

A theme sets the map’s colours, node shapes and connection lines, as the theme strip in the style sheet does; simpletree is the default. These names are the ones miMind’s AI assistant uses, and they never change:

The 52 theme names: standard, dark, pastel, flat, flatdark, trace, tracedark, underwater, nightvision, golden, engineer, picnic, beehive, explore, nautical, simple, simpledark, minty, office, office2, tron, tron2, blackonwhite, whiteonblack, simpletree, simpletree2, blueprint, sakura, midnight, terracotta, origami, slate, aurora, parchment, neon, forest, coral, sandstone, orchid, glacier, ember, meadow, inkwell, circuit, sorbet, harbor, canyon, lagoon, newsprint, bubblegum, obsidian, sunset.

{ "jsonrpc": "2.0", "id": 4, "method": "tools/call",
  "params": { "name": "create_map", "arguments": {
    "title": "Trip to Japan",
    "outline": "Week 1 - Tokyo\n  Shinjuku\n  Day trip to Nikko\nWeek 2 - Kansai\n  Kyoto temples\n  Osaka food tour\nBudget\nPacking list"
  } } }

{ "jsonrpc": "2.0", "id": 5, "method": "tools/call",
  "params": { "name": "create_map", "arguments": {
    "title": "The Apollo Program",
    "outline": "Apollo 8\nApollo 11\nApollo 13\nApollo 17",
    "layout": "orbital-station",
    "layout_options": { "spread": 1.2, "showRings": true }
  } } }

{ "jsonrpc": "2.0", "id": 6, "method": "tools/call",
  "params": { "name": "create_map", "arguments": {
    "title": "Arctic Expeditions",
    "outline": "Nansen and the Fram\nAmundsen's Northwest Passage\nPeary and Henson\nNobile's airship Italia",
    "background": "northern-lights"
  } } }

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "create_map", "arguments": {
    "title": "Garden Year",
    "outline": "Spring  — sow and prune\n  Seed potatoes\nSummer  — water early\nAutumn  — harvest and mulch",
    "theme": "sunset"
  } } }

Structured result: command_id, status (pending), title, map_id (only when it is certain), map_id_certain, theme (when one was given), normalized (what tidying did) and warnings.

add_nodes write

Queues new nodes for an existing map. They are added the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), with normal undo history, so you can always revert an agent’s additions; from miMind 26.11.6 each request is one step you can undo. Notes after — are written as each new node’s note by miMind 26.11.6 or later, as for create_map.

The parent must match

• parent_title is checked against the map’s published copy when the request is made, ignoring case and spacing. A line copied from read_map works too: its eN label, quotes, a bullet and the note are taken off. A bare label such as e5 is read as the title of the node at that position, with a note that labels are positions.
• No node with that title: the request is refused at once, with similar titles when there are any (No node titled "…" in "…" as last saved (…). Similar: …). If the user has just added the node, they save the map and the agent tries again.
• Several nodes with that title: the first one in tree order is used, and the reply says so.
• A title the copy shows cut at 160 characters (ending in …) is refused as shown: give the node’s full title, or pick another parent. In a map cut at 800 nodes, a title the copy does not show is queued with a note, since the node may lie past the cut.
• The map may change before it is opened. If the node is gone by then, miMind 26.10.31 and older add the nodes under the central topic; from miMind 26.11.6, nothing is added and the request fails with parent_not_found.
• With parent_eid or index the request is queued as an exact edit, like insert_nodes: it needs miMind 26.11.6 or later (older versions never apply it, and the reply warns device_update_needed when none of your recent devices can), the label is checked as described under Editing nodes, and a node that cannot be found when the map opens fails the request with target_changed. Without them, add_nodes works exactly as before.

{ "jsonrpc": "2.0", "id": 8, "method": "tools/call",
  "params": { "name": "add_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "parent_title": "Risks",
    "outline": "Supply chain delays\nKey-person dependency\nCurrency exposure"
  } } }

{ "jsonrpc": "2.0", "id": 9, "method": "tools/call",
  "params": { "name": "add_nodes", "arguments": {
    "map_id": "id_1731000000_5d7a",
    "parent_eid": "e17",
    "index": 0,
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "outline": "Book the venue  — before May\nDraft the invite list"
  } } }

The reply says where the nodes go: Queued (command <id>). The nodes will be added under "Risks" in "Product Roadmap" the next time the user opens that map in miMind. With parent_eid or index it names the label and the place too: … under "Launch" (e17) at position 0 in …. Structured result: command_id, status, map_id, title, parent_title (as queued), parent_eid, index and revision (with parent_eid or index, or when a revision was given: the place and the copy it was checked against), normalized and warnings.

set_background write

Sets the scene background behind an existing map: one of the built-in scenes, or none for a plain canvas. It is queued and applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo. A newer request for the same map replaces an older one that is still waiting, and a request not applied within 7 days lapses.

Scene backgrounds need a subscription in the app, which every miMind Business and AI plan includes; without one, miMind does not put the scene on (taking a scene away with none always works). miMind 26.9.23 and older never apply a set_background; 26.10.22 to 26.10.24, and possibly 26.10.30, do not show a scene marked (miMind 26.10.30+): such a request waits for an updated app and lapses after 7 days. Generating a new scene with AI is an in-app feature and is not offered here.

{ "jsonrpc": "2.0", "id": 10, "method": "tools/call",
  "params": { "name": "set_background", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "background": "misty-peaks"
  } } }

Structured result: command_id, status, map_id, title, background, scene (its name) and warnings.

get_command_status read-only

Says what became of a request that a write tool (create_map, add_nodes, set_background, insert_nodes, update_nodes, move_nodes or add_content) queued: still pending and what it waits for, done or failed with the app’s message, or expired, superseded, cancelled or refused. For a map create_map built, it gives the new map_id once it is known.

A request for your approval (propose_delete, propose_replace, revert_command) is pending while it waits in the map’s Agent Requests (Waiting for: the user to approve or reject it in miMind …), then done (with Approved by the user at …), rejected (with your reason, if you gave one), failed, expired, cancelled or refused (the map was deleted, hidden, encrypted or shared by someone else); a message (post_suggestion) is pending until you read it, then done. A request you undid in miMind stays done and warns undone_by_user; one a revert_command you approved took back warns reverted.

{ "jsonrpc": "2.0", "id": 11, "method": "tools/call",
  "params": { "name": "get_command_status", "arguments": { "command_id": "a7Kq2mXr9TzLpQ4vB1cD" } } }

Command a7Kq2mXr9TzLpQ4vB1cD: create_map "Trip to Japan" - done.
Queued 2026-11-01T10:02:11.000Z; picked up by a device at 2026-11-01T10:40:05.000Z; finished 2026-11-01T10:40:07.000Z.
Map created (map_id: id_1793527331_4be1…).
map_id: id_1793527331_4be1…

A pending request adds Waiting for: … (the next start of miMind, the user opening that map, an app new enough for a scene or an edit, or a device that has already started building it). When miMind did not report the new map’s id, it is looked up among the published maps, and a line such as probably map_id … (only map titled "…" published after it was built) says how sure that is.

Structured result: command_id, type, status, title, map_id, map_id_certain, created, completed, expires_at, picked_up_at, leased_until, message, result (what the app reported, from miMind 26.11.6), superseded_by, waiting_for and warnings; for an edit (insert_nodes, update_nodes, move_nodes, or add_nodes with parent_eid or index) also revision (the copy it was checked against) and ops (how many changes it holds).

The app’s result holds its code (created, applied, already_applied, or a failure code) and what it counted: nodes_added, nodes_requested and nodes_skipped for new nodes; ops_requested, ops_applied (0 when everything already was as asked), failed_op (which change stopped a failed edit; the message names it too) and bound (exact when the map had not changed since the read, anchors when the nodes were found by title and place) for an edit; notes_written and theme_applied for notes and a theme.

When miMind 26.11.6 or later applies a request that created nodes, it reports the ids it gave them: the structured result adds created_nodes[] (ref, the node’s place in the request such as n1, title and id), and the text a line such as Created: n1 "Q1" id:n3k9x0ab; n2 "Q2" id:n7c2d4ef. Name those nodes as id:… once the app has published the map again.

list_commands read-only

Lists the requests queued for your miMind app, newest first, each with its status and what it waits for or how it ended. Each is named by the tool that queued it.

{ "jsonrpc": "2.0", "id": 12, "method": "tools/call",
  "params": { "name": "list_commands", "arguments": { "status": "pending" } } }

One line per request: - <id> | add_nodes | "Product Roadmap" | pending | queued 2026-11-01T10:02:11.000Z | the user opening "Product Roadmap" in miMind, then (More: call list_commands with cursor "…".) when there are more. Structured result: commands[] and next_cursor. A request you rejected shows as rejected, under all; one you undid in miMind ends with The user undid it at ….

cancel_command write

Withdraws a request your miMind app has not applied yet; it changes the queue, never a map. Cancelling twice is harmless: a finished request is left as it is (Command <id> is already done; nothing to cancel.). A request a device is still holding (a create_map being built, for up to 10 minutes) may still be applied, and the reply says so. It also withdraws a request waiting for your approval, which then leaves your Agent Requests, or an unread message; one you have just approved, which your device is applying, may still be applied.

{ "jsonrpc": "2.0", "id": 13, "method": "tools/call",
  "params": { "name": "cancel_command", "arguments": { "command_id": "a7Kq2mXr9TzLpQ4vB1cD" } } }

Structured result: command_id, type, status, previous_status, cancelled and warnings.

Editing nodes: labels, titles and revisions

The edit tools change a map you already have: insert_nodes adds formatted nodes at an exact place, update_nodes renames nodes and changes their bold, colours, shape or date, and move_nodes moves nodes with their branches. add_nodes works the same way when it is given parent_eid or index. add_content adds content to nodes and text to the end of their notes. Each call is one request, applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6) as one change you can undo — all of it, or none of it. Nothing is deleted or replaced: adding content and adding to the end of a note are the only changes to what a node holds.

They need miMind 26.11.6 or later. Older versions never see these requests: they wait for an updated app and lapse after 30 days, and the reply warns device_update_needed when none of your recent devices can apply them.

Naming a node

• By label: an eN label from read_map names exactly that node, even when others share its title. Pass the read’s revision with it.
• By title: a title only one node in the map has, as read_map shows it (case and spacing ignored). When several nodes have it the request is refused with their labels (e3 Budget, e17 Budget), and when none has it, with up to five similar titles. A title the copy shows cut at 160 characters, or a node a long map’s copy does not reach, cannot be named that way: pick a node the copy shows, by its label, or by its id.
• By id (from miMind 26.11.6): id:n3k9x0ab, an id from get_node or read_map format json, names that node wherever it is now, after renames and moves too, and needs no revision. Write the id:: a bare string is always a title. It needs a full copy of the map; an id the copy does not have is refused and never taken for another node. When the map opens, miMind finds such a node by its id alone: if it is gone, the request fails with target_changed. add_nodes does not take ids.

Revisions

• read_map’s structured result carries revision, a fingerprint of the copy it read. Given with labels, it is checked against the copy now on the server: once the map has been saved again the request is refused (… has changed since that read …) and nothing is queued; read the map again for fresh labels. A string that is not a revision is refused too (… is not a revision read_map gave …).
• Labels given without a revision are read against the current copy, and the reply warns revision_assumed and says which node each label named.
• When the map opens, miMind finds each node the request named: directly when the map is still as it was read, otherwise by its title, its parent’s title and its depth (the label’s number decides between nodes that share all three). A node it cannot find that way fails the whole request with target_changed, and nothing changes. Requests queued after one read all apply, in order: one that adds or renames nodes does not throw off the labels of the next.

Formatting

• Colours (fill_color, text_color, border_color): #RRGGBB; #RGB, and either without the #, are accepted.
• Shapes: rectangle, rounded, rounded25, capsule, ellipse, diamond, cloud, hexagon.
• Dates, for the timeline-dated layout: "1969-07-20", "1969-07", "1969", "-0044" (44 BC), or a number for a numeric scale.
• Setting a colour or a shape changes only that: the node keeps its frame, shadow and fill as they were.

Premium layouts

On a device whose plan has no premium layouts, a request that adds, renames, bolds, dates or moves nodes in a branch arranged by a premium layout fails whole with premium_layout, and nothing changes; colours and shapes are not limited. No upgrade prompt opens. Every miMind Business and AI plan includes premium layouts.

insert_nodes write

Queues new nodes for an existing map, at an exact place, each with its title and, if wanted, a note, bold, fill, text and border colours, a shape and a date. Nodes nest by level. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo. Nothing is deleted or replaced.

{ "jsonrpc": "2.0", "id": 14, "method": "tools/call",
  "params": { "name": "insert_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "parent": "e4",
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "index": 0,
    "nodes": [
      { "title": "Vendor lock-in", "bold": true, "fill_color": "#FFE08A" },
      { "title": "Keep a second supplier warm", "level": 1, "note": "Quarterly check-in" },
      { "title": "Hiring freeze", "shape": "capsule" }
    ]
  } } }

The reply: Queued (command <id>). 3 nodes will be added under "Risks" (e4) at position 0 in "Product Roadmap" the next time the user opens that map in miMind, as one change the user can undo. Structured result: command_id, status, map_id, title, parent_eid, parent_title, index (when given), nodes_requested, revision (the copy the request was checked against) and warnings.

update_nodes write

Queues changes to nodes a map already has: a new title, bold on or off, fill, text and border colours (for a whole branch with subtree), a shape and a date. Nothing is deleted, and no note or content changes. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo.

A change needs at least one field besides node and subtree, and subtree goes only with a colour. A title cannot be cleared. Several changes may name the same node; they apply in order.

{ "jsonrpc": "2.0", "id": 15, "method": "tools/call",
  "params": { "name": "update_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "changes": [
      { "node": "e1", "title": "Q3 2027", "bold": true, "fill_color": "#FFCC00", "subtree": true },
      { "node": "Pricing page", "shape": "diamond", "border_color": "#C0392B" }
    ]
  } } }

The reply lists up to ten changes, then (and … more):

Queued (command <id>). 2 changes to "Product Roadmap" will be applied the next time the user opens that map in miMind, as one change the user can undo:
- e1 "Q3": renamed to "Q3 2027"; bold; fill #FFCC00 (whole branch)
- e3 "Pricing page": border #C0392B; shape diamond

Structured result: command_id, status, map_id, title, revision, changes[] (node, title as the copy spells it, fields) and warnings.

move_nodes write

Queues moves of nodes a map already has, each with its whole branch: under another parent (parent, and index if wanted), or to another place among its siblings (index alone). Nothing is deleted. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo.

• Every label names the node as read_map showed it, even after an earlier move of the same call.
• Central topics stay where they are in this version, and a node cannot move into its own branch, including a branch an earlier move of the same call made: both are refused when the request is made. A move needs parent, index or both.

{ "jsonrpc": "2.0", "id": 16, "method": "tools/call",
  "params": { "name": "move_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "moves": [
      { "node": "e4", "parent": "e1", "index": 0 },
      { "node": "e2", "index": 2 }
    ]
  } } }

The reply lists up to ten moves, then (and … more); a move with parent and no index goes after its last child:

Queued (command <id>). 2 moves in "Product Roadmap" will be applied the next time the user opens that map in miMind, as one change the user can undo:
- e4 "Risks" -> under e1 "Q3" at position 0
- e2 "Launch beta" -> position 2 among its siblings

Structured result: command_id, status, map_id, title, revision, moves[] (node, title, parent, parent_title, index when given) and warnings.

Reading in depth: the full copy and ids

The tools below, like read_map’s formats, read the full copy that miMind 26.11.6 or later publishes beside the outline: whole titles and notes, styles, dates, check boxes, content and cross-links, for up to 2,000 nodes, each with its id. They read the copy published at the last save, never the map itself, and change nothing.

• Every map works. A map an earlier version published has the outline alone. The tools still answer from it, with what the outline holds (titles and notes cut at 160 characters; no styles, tasks, dates, content or cross-links), and say so: the structured result has source outline instead of detail, and the text ends with a note that the copy holds only the text outline and that saving the map in an updated app publishes the rest. That is never an error.
• Naming a node (get_node, and read_map’s node): an eN label with its read’s revision, id:<id>, or a title only one node has. A revision that is no longer current is refused (The revision you gave is not the current copy of "…" (now …): read the map again for its current labels.). A full copy holds more nodes than the outline, so its labels go on past e799.
• Hidden and removed maps answer No map with map_id "…", as everywhere.

get_node read-only

Reads one node in full: its path from the central topic, its whole note, its style, its date, whether it is collapsed, its content (check boxes and whether they are ticked, text, links and web images with their addresses, tables by size), its children and its cross-links. It reads the copy published at the last save.

{ "jsonrpc": "2.0", "id": 17, "method": "tools/call",
  "params": { "name": "get_node", "arguments": { "map_id": "id_1731000000_5d7a", "node": "id:n3k9x0ab" } } }

Node e12 "Budget" in "Plan" (map_id: id_1731000000_5d7a, revision 9B2F0C61D4E8A7735A1C0E96F3B2D418)
Id: n3k9x0ab
Path: e0 Plan › e3 Finance › e12 Budget
Note: Numbers from the March review; final once the board signs off.
Style: fill #336699, text #000000, border #333333, shape rounded, bold
Date: 2026-11-05
Collapsed
Content (2):
- [x] Approve budget
- link: Spec https://example.com/spec
Children (2):
- e13 Q1 (4 children)
- e17 Q2
Cross-links (1):
- to e40 Hiring "depends on"

A line with nothing to say is left out. At most 200 children are listed, then … and 12 more: read_map with node=e12, depth=1. On a copy with the outline alone, only the title and note (as the outline cut them), the path and the children are known, and the reply says so.

Structured result: map_id, title, revision, source and node: eid, id, parent, depth, title, note, children (how many), collapsed, date, layout (on a central topic), style (fill, text, border, shape, bold, italic), content[] (kind, text, checked, url, rows, cols) and truncated, plus path[], child_list[], children_total and links[] (direction to or from, eid, id, title, label).

get_map_info read-only

Describes a map without reading all of it: how many nodes the copy holds and the map has in all, its central topics and how deep it goes, how many nodes have notes, are collapsed or have dates, how many tasks are open and done, how many cross-links and content items of each kind it has, and its theme, layout, scene and background colour. On a copy with the outline alone, what only the full copy can tell is left out, and the reply says so.

{ "jsonrpc": "2.0", "id": 18, "method": "tools/call",
  "params": { "name": "get_map_info", "arguments": { "map_id": "id_1730450000_9f2c" } } }

The reply is about ten lines: the map; when it was updated, its revision and who published it; the node counts; tasks, dates and cross-links; content; style; then the central topics (up to 50).

Structured result: map_id, title, node_count, updated, revision, truncated, source, published_by (app, version, platform), counts (in_copy, total, roots, max_depth, notes, collapsed, tasks_open, tasks_done, dated, cross_links, and content by kind), style (theme, layout, scene, scene_title, background) and roots[] (eid, id, title, children, layout).

read_tasks read-only

Lists check-box tasks and dated nodes, across your maps or in one: open tasks by default. A task is a check box in a node’s content; a dated node is one with a date, as a timeline-dated layout places it (a task takes its node’s date). Each item names its map, its node’s label, id and path, and its date. A call counts as 5 towards the rate limit.

{ "jsonrpc": "2.0", "id": 19, "method": "tools/call",
  "params": { "name": "read_tasks", "arguments": {} } }

Open tasks — 14 in 3 maps (25 maps scanned):

"Plan" (map_id: id_1731000000_5d7a)
- [ ] Approve budget — Plan › Finance › Budget (e12, due 2026-11-05)

• Items come map by map, in each map’s tree order; with a date filter, by date, and the head says the range (Open tasks due 2026-11-01 to 2026-11-30 — …). A date (kind dates) reads - 2026-11-05 Kickoff — Plan › Schedule (e30). An unknown value reads as the default, and a date the tool cannot read is ignored, with a word in the reply.
• Without map_id it looks through up to 200 maps a call, newest first, and reads in full only those whose full copy has what was asked, up to 25 a call; it stops at limit items or about 45,000 characters, with a cursor for the rest.
• Maps an earlier version published have no tasks or dates the tool can see: the reply counts them and says that saving them in an updated app publishes them. With nothing found it says No open tasks found (25 maps scanned).

Structured result: kind, status, items[] (map_id, map_title, eid, id, node_title, path, kind check or date, text, done, date), scanned, without_detail and next_cursor.

list_catalog read-only

Lists the names the other tools accept, so an agent can choose without guessing: the themes, and which of them come with the app at no extra cost; the layouts create_map takes, basic or arranged, with what each looks like; the scenes set_background offers, with their name, group and whether they are still, and none; and the shapes, with the other names each accepts; the line styles and animations connect_nodes takes; and the fonts, node shapes and numbering format_nodes takes; and the templates build_map takes, by category; and, for set_scene, the names of your own saved scenes and the scene JSON it takes. It reads no map, only your saved scenes’ list for my_scenes.

{ "jsonrpc": "2.0", "id": 20, "method": "tools/call",
  "params": { "name": "list_catalog", "arguments": { "kind": "themes" } } }

Structured result, for the kinds asked: themes[] (id, free), layouts[] (id, group basic or arranged, look), scenes[] (id, title, category, still) and shapes[] (id, aliases); and layout_families[] (id, group, directions, the create_map names that map to it, and dials[] with each dial’s key, type and range or values), arranged_themes[] (id, layouts) and washes[]; and lines (patterns, types, ends, width with its min and max) and animations (effects, directions, transitions, speeds, count with its min and max); and fonts (families, and size with its min and max), node_shapes[] (id, aliases) and numbering (types, none among them; colorings; aligns; size with its min and max); and templates (revision, and categories[] with each category’s name, its templates, which of them are premium, and those that need a newer miMind, with the version). A premium template is built only where your plan includes it. my_scenes[] (id, name — your own words, which the tool tells the agent to treat as data —, created, source ai, map or import) and scene_format (text: the keys, layers, colour roles, motion and limits miMind’s scene check enforces), each only for its own kind and once switched on; until then both kinds answer as all.

get_sync_status read-only

Says who this connection is signed in as and how your miMind apps sync: the email the token was made with, the token’s label and how it starts, how many maps are published and hidden and when the last one was published, the devices that picked up requests in the last 30 days (version, platform and what each can do), and how many requests are waiting. It shows no device name or id, and nothing about your plan.

{ "jsonrpc": "2.0", "id": 21, "method": "tools/call",
  "params": { "name": "get_sync_status", "arguments": {} } }

Signed in with a token made by user@example.com ("Claude Desktop", mmcp_ab12cd3…, made 2026-10-30).
Maps: 42 published, 3 hidden from agents; last publish 2026-11-01 10:22 UTC.
Devices seen in the last 30 days (2):
- miMind 26.11.3 on iOS: seen 2026-11-01 10:20 UTC; can create maps, add nodes, backgrounds, layouts, themes, notes, edits, full copy
- miMind 26.10.31: seen 2026-10-30; can create maps, add nodes, backgrounds, layouts (an updated miMind app adds themes, notes, edits and the full copy)
Pending requests: 2 (list_commands shows them).

When the server cannot count the maps, it says unknown how many; with nothing waiting, Pending requests: none. Structured result: account (email, token_label, token_prefix, token_created), maps (published, hidden, last_publish), devices[] (app, version, platform, generation, last_seen, last_pull, abilities[]), pending_commands and update_hint. While requests for your approval are switched on, a device of miMind 26.11.6 or later adds approvals of deletes and replacements to what it can do, and the pending line adds … of them wait for the user's approval or reading in the app. when such requests or messages wait. While file requests are switched on, a device of miMind 26.11.6 or later also lists file and folder requests, and while map links or the trash are, map links and trash requests. Once switched on, a device of the next miMind update also lists drawings, items inside notes, content order, scenes, title lists plus review approvals and items inside notes in the copy, and a line says whether review is on: Review: off, Review: on - agent changes to existing maps wait for approval in the latest version of the miMind app. (with None of this account's devices can approve them yet. when none can), or Review: on, but paused - agent changes apply directly.

add_content write

Queues content for nodes a map already has: body text, link cards, pictures and videos by web address; check boxes and radio buttons, check lists, choice and switch groups, lists and tables; pie, bar and line charts, places on a map, calendar cards and emoji; and text added to the end of a node’s note. Everything is added after what the node already has: nothing is removed, replaced or reordered, and an existing note keeps its text and formatting. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses, and the reply warns device_update_needed when none of your recent devices can apply it.

Types

Refused with a hint: audio, sound and music (add the address as a link), and icon, sticker, alarm, attachment, maplink and gantt, which agents cannot add. A field the type does not take is refused, and so is a second note for one node in a call (join the texts). A refusal names the addition and why, and nothing is queued.

Pictures, videos and links

This server never opens an address an agent gives: it checks it offline and queues it. Only public http and https addresses are taken: no user name or password, no IP address, no local name such as localhost or printer.local, and no port but 80 and 443. There is no image search: give the address of the picture file. An image whose address ends in no picture file extension is queued with the warning media_unverified; a web page, video or audio address is refused, with the type to use. A video must be one miMind can play: a YouTube or Vimeo video page, or a direct .mp4, .webm, .mov, .m4v, .ogv, .mkv or .avi file; anything else is refused, to be added as a link.

When the map opens, the user’s device does the fetching: it places a tile for each picture at once and downloads it afterwards, so applied means placed. A picture that fails to download shows that on its tile, and the request still counts as one change to undo. A link stays a link card and a video a video, whatever the address looks like. Places are looked up by the device too.

On a device whose plan does not include a kind of content (pictures, video, tables, charts, places or calendar cards), the request fails whole with premium_content, and nothing changes; no upgrade prompt opens. Every miMind Business and AI plan includes them all. Content and notes may be added in a branch arranged by a premium layout.

{ "jsonrpc": "2.0", "id": 22, "method": "tools/call",
  "params": { "name": "add_content", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "additions": [
      { "node": "e12", "type": "table", "title": "Costs", "headers": ["Item", "Q1", "Q2"],
        "rows": [["Venue", 1200, 1350], ["Food", 340.5, 410]] },
      { "node": "e12", "type": "image", "url": "https://example.com/venue.jpg" },
      { "node": "e12", "type": "note", "text": "Checked by Dana on 3 November." },
      { "node": "id:n3k9x0ab", "type": "checkgroup", "title": "Steps",
        "items": ["Post the job", "Screen", { "text": "Interview", "checked": true }] }
    ]
  } } }

The reply starts Queued (command <id>). 4 additions to 2 nodes of "Product Roadmap" will be made the next time the user opens that map in miMind, as one change the user can undo: and gives a line for each node (up to ten), naming a node given by id by its id:. Structured result: command_id, status, map_id, title, revision, additions[] (node, id when it was named by id, title, type, and media card, picture or video for an address) and warnings.

set_map_style write

Queues a new look for a map you already have: its layout (a family and direction from list_catalog, with that layout’s dials) for the whole map, one central topic’s tree or one branch; its theme, for the map or a branch, including the arranged layouts’ own themes; the canvas (a colour, a gradient wash, or a scene with its dials); and where the central topics sit. Nothing is deleted, and no node’s text, note or content changes. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo: Undo puts the layouts, dials, themes and canvas back exactly as they were. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses, and the reply warns device_update_needed when none of your recent devices can apply it.

On a device whose plan does not include an arranged layout, a theme or a scene, the request fails whole with premium_layout, premium_theme or premium_scene, and nothing changes; no upgrade prompt opens. While you have the style sheet, a theme or a scene preview open in the app, the request waits, and it is applied once you close it, so your own changes and the agent’s stay separate steps.

{ "jsonrpc": "2.0", "id": 23, "method": "tools/call",
  "params": { "name": "set_map_style", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
    "layouts": [ { "layout": "coil", "dials": { "pitch": 200 } },
                 { "node": "e12", "layout": "fishbone", "direction": "down" } ],
    "themes": [ { "node": "e12", "theme": "fishbone-chalk" } ],
    "canvas": { "scene": { "id": "northern-lights", "depth": 0.4 } }
  } } }

The reply starts Queued (command <id>). and lists the changes. Structured result: command_id, status, map_id, title, revision, changes[] (what layout, theme, canvas or arrange; node, empty for the whole map; node_title; summary) and warnings[].

add_central_topics write

Queues new central topics for a map you already have: each is a tree of its own, optionally with nodes under it (as insert_nodes takes them, each with its own content as add_content takes it), its own layout and dials, and its own theme. Nothing is deleted or replaced, and the trees the map has stay where they are unless arrange says otherwise; new topics are placed clear of every tree. Applied the next time that map is open in miMind (at once if it is open now, from miMind 26.11.6), as one change you can undo; once it is done, get_command_status lists the ids of the new central topics and nodes. It needs miMind 26.11.6 or later.

{ "jsonrpc": "2.0", "id": 24, "method": "tools/call",
  "params": { "name": "add_central_topics", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "topics": [
      { "title": "Hiring plan", "layout": "fishbone", "direction": "right", "theme": "fishbone-clinic",
        "nodes": [ { "title": "Roles" },
                   { "title": "Engineer", "level": 1,
                     "content": [ { "type": "checkbox", "text": "Post the job" } ] } ] },
      { "title": "Open questions", "bold": true }
    ],
    "arrange": "around"
  } } }

The reply starts Queued (command <id>). Structured result: command_id, status, map_id, title, revision, topics[] (id, its n1-style name in the request, title, nodes, how many go under it) and warnings[]. Once the app has applied it, get_command_status gives each new node’s id:, the central topics’ included.

connect_nodes write

Queues new cross-links between nodes of a map you already have, and changes to lines it has: a label (set or renamed, never removed), the colour, pattern, width, type and end shapes, hiding or showing a line, returning a hand-bent cross-link to its automatic path, and added animations. The lines into a node, a whole branch or the whole map can be restyled at once. Nothing is deleted: no line, label or animation is removed, and no node changes. Applied the next time that map is open in miMind (at once if it is open now; see Live delivery), as one change you can undo: Undo removes the new links and puts every line back as it was. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses, and the reply warns device_update_needed when none of your recent devices can apply it.

Line styles

A style is an object with any of color (#RRGGBB), pattern, width (2 to 16), line_type, start and end (the shapes at each end). An animation is an object with effects (1 to 4 different ones), an emoji that travels along the line, or both; and optionally direction, speed, count (1 to 8), enter and exit. A number out of range is set to the nearest one in range, and a speed to the nearest one listed, with the warning value_clamped; a name not listed is refused. list_catalog kinds lines and animations list the same names.

A line of an arranged layout is drawn by the layout itself: restyling it warns use_layout_dials, since set_map_style’s dials change those lines. On a device whose plan does not include connection animations, a request that adds one fails whole with premium_animation, and nothing changes; no upgrade prompt opens. While you are editing a line’s label or have the line style or animation panel open, the request waits until you finish.

{ "jsonrpc": "2.0", "id": 25, "method": "tools/call",
  "params": { "name": "connect_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "links": [ { "from": "Budget", "to": "Hiring", "label": "funds",
                 "style": { "color": "#E4572E", "pattern": "dashed", "end": "arrow" },
                 "animations": [ { "effects": [ "pulse" ], "speed": 1 } ] } ],
    "lines": [ { "node": "Risks", "branch": true, "style": { "width": 4, "line_type": "curved" } } ]
  } } }

The reply starts Queued (command <id>). and lists the changes. Structured result: command_id, status, map_id, title, revision, changes[] (what link, line or lines; from and to, the eN labels of the line’s two ends, a tree line’s parent first, both empty for every line of the map; from_title; to_title; summary) and warnings[].

format_nodes write

Queues formatting for nodes of a map you already have: the title’s font, size and colour, its bold, italic, underline, strike-through, highlight and alignment, and the formatting of words inside it (spans, found by their text: the words never change); the node’s shape (30 shapes), frame, shadow, aspect, size and rotation; numbering of its children; centred content; grouping; and the look of its notes (never their text). Font, emphasis and shape can go to one node, its children, its branch, a level or the whole map. Nothing is deleted and no text changes. Applied the next time that map is open in miMind (at once if it is open now; see Live delivery), as one change you can undo: Undo puts every node back as it looked. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses, and the reply warns device_update_needed when none of your recent devices can apply it.

Fonts, node shapes and numbering

A name not listed is refused, and the refusal lists the names; a font is matched ignoring case, spaces and dashes. A number out of range is set to the nearest one in range, with the warning value_clamped. list_catalog kinds fonts, node_shapes and numbering list the same names.

Formatting a node in a branch arranged by a premium layout you have no subscription for fails the whole request with premium_layout, and nothing changes; no upgrade prompt opens. Fonts, shapes, numbering and grouping need no subscription. A font the device is still downloading makes the request wait for it, and so does a font, shape or colour panel you have open, the full-screen notes editor, or typing in the notes.

{ "jsonrpc": "2.0", "id": 26, "method": "tools/call",
  "params": { "name": "format_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "changes": [
      { "node": "Budget", "font": { "family": "LiberationSerif", "size": 22, "color": "#1F3A93" },
        "text": { "bold": true }, "shape": "octagon", "shadow": true },
      { "node": "Hiring", "spans": [ { "match": "two engineers", "bold": true, "highlight": "#FFE066" } ] },
      { "node": "Risks", "scope": "children", "text": { "italic": true } },
      { "node": "Q1", "numbering": { "type": "numeric", "coloring": "parent" } }
    ]
  } } }

The reply starts Queued (command <id>). and lists the changes. Structured result: command_id, status, map_id, title, revision, changes[] (node, node_title, scope, fields, the formatting keys given, and summary) and warnings[].

set_node_state write

Queues state changes in a map you already have: ticks or clears check boxes and picks radio buttons (named by their text, as read_tasks and get_node show them), collapses or expands branches (or the whole map to a level), and focuses one node: selects it and scrolls it into view. Nothing is deleted and no text changes. Applied the next time that map is open in miMind (at once if it is open now; see Live delivery), as one change you can undo; focusing is not an undo step. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses.

Check boxes, folding and focus need no subscription. While you are editing that group of check boxes, the request waits until you finish. Folding is your device’s own view: it is not shared with the people you share a map with.

{ "jsonrpc": "2.0", "id": 27, "method": "tools/call",
  "params": { "name": "set_node_state", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "checks": [ { "node": "Hiring", "item": "Post the job", "checked": true } ],
    "folding": [ { "action": "to_level", "level": 2 } ],
    "focus": "Hiring"
  } } }

The reply starts Queued (command <id>). and lists the changes. Structured result: command_id, status, map_id, title, revision, changes[] (what check, fold or focus; node; node_title; summary) and warnings[].

copy_nodes write

Queues copies of branches in a map you already have: each node with everything under it (titles, notes, content and styling) is copied next to itself, under another node, or as a new central topic. Cross-links inside a branch are not copied. Nothing is deleted or moved; move_nodes moves a branch. Applied the next time that map is open in miMind (at once if it is open now; see Live delivery), as one change you can undo; once it is done, get_command_status lists the ids of the copies. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses.

Copying from or into a branch arranged by a premium layout you have no subscription for fails the whole request with premium_layout; a copy that would land inside its own branch fails with cycle. A copied branch that holds cross-links is copied without them, and the reply warns links_not_copied. Each copy gets node ids of its own.

{ "jsonrpc": "2.0", "id": 28, "method": "tools/call",
  "params": { "name": "copy_nodes", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "copies": [ { "node": "Q1", "parent": "Q2", "index": 0 },
                { "node": "Template", "as_central_topic": true } ]
  } } }

The reply starts Queued (command <id>). Structured result: command_id, status, map_id, title, revision, copies[] (id, its n1-style name in the request; node; title; parent; parent_title; nodes, how many it copies) and warnings[]. Once the app has applied it, get_command_status gives each copy’s id:.

refine_map_style write

Queues refinements of a map’s style: the spacing between a node’s sub-nodes (one node, its branch, or every central topic); giving nodes back the style sheet’s defaults or the theme’s styling (this discards the hand-set colours, shapes, fonts and lines of those nodes, as the style sheet’s own buttons do); and the map’s glow and flowing-line effects. No node, text or content is deleted. Applied the next time that map is open in miMind (at once if it is open now; see Live delivery), as one change you can undo: Undo brings back exactly the look the nodes had. It needs miMind 26.11.6 or later; older versions leave it waiting until it lapses.

Spacing or restyling inside a branch arranged by a premium layout you have no subscription for fails the whole request with premium_layout, and nothing changes. While you have the style sheet or the layout panel open, the request waits until you close it.

{ "jsonrpc": "2.0", "id": 29, "method": "tools/call",
  "params": { "name": "refine_map_style", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "spacing": [ { "node": "Risks", "gap": 40, "branch": true } ],
    "restyle": [ { "node": "Budget", "to": "theme" } ],
    "effects": { "glow": { "on": true, "strength": 0.6 } }
  } } }

The reply starts Queued (command <id>). and lists the changes. Structured result: command_id, status, map_id, title, revision, changes[] (what spacing, restyle or effects; node, empty for the map’s effects; node_title; summary) and warnings[].

propose_delete write

Asks you to approve deleting parts of a map: nodes (each with everything below it), cross-links, content items, the labels of cross-links, or every animation of a line. Nothing changes when the agent calls it: the request waits in that map’s Agent Requests in miMind, where you see what would go, and is applied only when you approve it, as one change you can undo; you can reject it instead, and tell the agent why. Unanswered, it lapses after 14 days. It needs miMind 26.11.6 or later; earlier versions never show it, and it lapses.

Every node it names, and both ends of every cross-link, must be found for certain: when you approve, the app finds them by their ids, or only in the very copy the agent read, never by title and place again; a request whose nodes it can no longer find fails with target_changed and changes nothing. Links, labels, animations and content need the map’s full copy (content, one of a map small enough that the copy lists its items). Deleting every central topic is refused: a map keeps at least one. What the request already deletes with a node (a node inside it, a link, line or item that goes with it, the label or animations of a link it removes) is left out with the warning inside_other_delete, and a label that is already empty with no_label. More than 200 nodes in all warn delete_large, and another waiting request that names the same node or link warns proposal_overlaps.

{ "jsonrpc": "2.0", "id": 30, "method": "tools/call",
  "params": { "name": "propose_delete", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "reason": "These ideas were replaced by the Q3 plan.",
    "nodes": [ { "node": "Old ideas" } ],
    "links": [ { "from": "Q3", "to": "Budget" } ]
  } } }

The reply starts Queued (command <id>) for the user's approval in miMind:, lists the changes (- node e12 "Old ideas" and the 4 nodes below it) and ends Nothing changes until the user approves it; it lapses unapproved after 14 days. Structured result: command_id, map_id, title, status (pending), expires_at, revision, ops, nodes_deleted (the nodes named and everything below them), changes[] (what node, link, label, animations or content; node, node_title, from, from_title, to, to_title, nth, place, kind and below as they apply; summary) and warnings[].

propose_replace write

Asks you to approve replacing what a map already has: a node’s notes (overwritten, or cleared with ""; their look is kept), a line’s animations, the text of a text, check-box or radio-button item, or new items at the end of an existing check-box or radio-button group. As with propose_delete, nothing changes until you approve it in the map’s Agent Requests; then it is one change you can undo. It lapses after 14 days unanswered, and needs miMind 26.11.6 or later.

Its names are checked as propose_delete’s are. A check box or radio button that is in no group gets the new items as boxes of its own, after the node’s last item. Notes that hold pictures or files cannot be replaced by a request: approving one fails with notes_rich and changes nothing. When the map’s last copy showed only part of a note (or none of it), the reply warns note_unseen_part: you see the whole note before you approve. An animation’s count or speed out of range warns value_clamped, and another waiting request on the same node or link proposal_overlaps.

{ "jsonrpc": "2.0", "id": 31, "method": "tools/call",
  "params": { "name": "propose_replace", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "notes": [ { "node": "Budget", "text": "Approved in March.\nReview in June." } ],
    "content": [ { "node": "Venue", "item": "Book venue", "kind": "check", "text": "Book the venue" } ]
  } } }

The reply starts Queued (command <id>) for the user's approval in miMind: and lists the changes (- the notes of "Budget" (replaced: 34 characters)). Structured result: as propose_delete’s without nodes_deleted, with what note, animations, content or group.

revert_command write

Asks you to approve taking back what an earlier request added to a map: the nodes it created are deleted, with everything now below them. Its other changes (renames, moves, formatting, a new look) are not taken back: the reply names them, and the tools that set them back. As with the other requests for your approval, nothing changes until you approve it in the map’s Agent Requests (then it is one change you can undo), and it lapses after 14 days.

It takes back a request miMind 26.11.6 or later applied (that version reports the ids of the nodes it created), while those nodes are in the map’s last copy. It refuses a request still pending (withdraw it with cancel_command), one that failed or changed nothing, one you already undid in miMind, and one you approved through Agent Requests (only miMind’s Undo brings deleted content back). When nodes added later sit below a node it would delete, the reply warns revert_includes_later_nodes; when the request changed more than it created, revert_partial; another waiting request on the same nodes, proposal_overlaps. Once you approve it, get_command_status of the request it took back warns reverted.

{ "jsonrpc": "2.0", "id": 32, "method": "tools/call",
  "params": { "name": "revert_command", "arguments": {
    "command_id": "a7Kq2mXr9TzLpQ4vB1cD", "reason": "Those were added to the wrong map."
  } } }

The reply starts Queued (command <id>) for the user's approval in miMind: and names the nodes it would delete. Structured result: command_id, reverts (the request it takes back), map_id, title, status, expires_at, ops, nodes[] (ref, the node’s n1-style name in that request; title; id; below, how many of its other nodes are below it), not_reverted[] and warnings[].

post_suggestion write

Leaves you a short plain-text message in miMind’s Agent Requests: on the map it names (and the node, if any), or, without map_id, on every map you open; the MCP Server dialog lists it too. It changes nothing. You read it and mark it as read; unread, it lapses after 30 days. Links and markup show as typed and are never opened. It needs miMind 26.11.6 or later.

{ "jsonrpc": "2.0", "id": 33, "method": "tools/call",
  "params": { "name": "post_suggestion", "arguments": {
    "map_id": "id_1730450000_9f2c", "title": "Two branches overlap",
    "text": "\"Marketing\" and \"Launch\" list the same three tasks. You may want to merge them."
  } } }

The reply: Queued (command <id>): a message for the user in miMind's Agent Requests. It changes nothing and lapses unread after 30 days. Structured result: command_id, status (pending until you read it, then done), expires_at, map_id, node and warnings[].

propose_trash_map write

Asks you to approve moving one map to the trash: the only way an agent can remove a map. Nothing changes when the agent calls it: the request waits in that map’s Agent Requests (and in the MCP Server dialog’s list), and only when you approve it, on a device that has the map, does miMind close the map if it is open there and move its file to that device’s trash, under a name no other entry of that trash has. It can be recovered from there for 90 days, with recover_map or in miMind, only on that device. Unapproved, it lapses after 14 days. It needs miMind 26.11.6 or later; earlier versions list it as a request they cannot show, which you can reject there.

Refused, and nothing queued, for a map that is not published, hidden from agents, encrypted or someone else’s; for a map you share with others (stopping sharing stays in miMind: ask the user to stop sharing it first); and while another request to trash the same map waits. When you approve it, the server checks again and nothing changes when the map is now shared with others, or open on another of your devices with an up-to-date app and sync on (close it there, then approve again). The reply warns place_device when the map’s file is on one device only (approve it there) and map_open when the map is open on one of your devices.

{ "jsonrpc": "2.0", "id": 40, "method": "tools/call",
  "params": { "name": "propose_trash_map", "arguments": {
    "map_id": "id_1730450000_9f2c",
    "reason": "Launch 2026 replaced this plan."
  } } }

The reply: Queued (command <id>) for the user's approval in miMind: move "Launch 2025" to the trash. Nothing changes until the user approves it; it lapses unapproved after 14 days. Follow it with get_command_status. Structured result: command_id, map_id, title, status (pending), expires_at and warnings[]. Once the map is in the trash, get_command_status says so (code trashed) and list_files with in_trash lists it.

list_files read-only

Lists your maps with where their files are — the drive, the folder and the file name, as miMind last published them — and the folders that hold them, 100 maps a page: by drive (in the order below), folder and file name, then the maps whose place is not known, newest first. Places are known only once our server shares them (they are switched on in stages, after the privacy wording is published), and only for maps an up-to-date miMind published with Sync my maps to the MCP server on; other maps show empty places. A folder without a published map is not listed. With in_trash it lists instead the maps an approved propose_trash_map moved to the trash in the last 90 days, for recover_map. Each map’s url opens it in miMind on a device that has it, once map links are switched on; until then it is "". It reads the 2,000 most recently saved maps, and a call counts as 5 requests.

{ "jsonrpc": "2.0", "id": 41, "method": "tools/call",
  "params": { "name": "list_files", "arguments": { "drive": "cloud", "folder": "Plans" } } }

Structured result: maps[] (map_id, title, drive, folder, file without its extension, updated, url; "" where not known), folders[] (drive, path, maps; first page only), with in_trash trashed[] (map_id, title, drive, folder, file, trashed_at, recoverable_until, and device, the platform of the device that holds it, never an id), index (on, off, or partial when some maps have no known place), next_cursor and warnings[]: file_index_off (no places are shared), index_partial, list_cut (only the 2,000 most recently saved maps were read: narrow it with drive and folder) and trash_off (the trash is not switched on: nothing is listed from it).

build_map write

Queues a new map for your miMind app to build, like create_map but with more: several central topics with their nodes, notes, dates and content (topics); or text in a format — an indented outline, Markdown, OPML, FreeMind, CSV or JSON — that the server turns into nodes; or a template from list_catalog (kind templates); and where its file goes (drive, folder and file name). One device builds it with miMind 26.11.6 or later, while it runs (at once) or when it starts, and publishes it at once; get_command_status gives the new map_id. If the folder already holds a file of that name, the new one gets “ (2)”, “ (3)” and so on: nothing is ever replaced. It lapses after 30 days, and a call counts as 3 requests. create_map keeps working with every version.

Text formats

Text is turned into nodes on our server before anything is queued; miMind’s own importers never see what an agent sends, and no web address, path or file named in the text is ever opened by anyone. Markdown: headings make the levels (one top heading is the central topic, several are several), list items nest under the last heading, paragraphs and quotes become the previous node’s note and code its note text; pictures, tables, HTML and the addresses of links are left out (a link keeps its text). OPML and FreeMind: a strict subset of XML (no DOCTYPE or entities); outline text or node text makes the titles, notes stay notes. CSV: one table on the central topic, the first row its headers, at most 50 rows of 20 columns and 1,000 cells. JSON: objects with title (or text or name), note and children (or nodes or items) become nodes, and anything else is listed key by key. In every format the text is at most 256 KiB, the map at most 5,000 nodes, titles one line of up to 1,000 characters and notes up to 10,000 (longer ones are cut), more than 20 top-level items go under one central topic named title, and nodes deeper than 30 levels are placed at level 30.

A template is miMind’s own catalogue’s: the app downloads it from there, and builds a premium one only where your plan includes it (otherwise the request fails premium_template), and one that needs a newer miMind only on a device that has it (template_needs_update). The reply warns map_id_unknown when some recent device could not build it (the id comes once it is built); about the text, import_dropped (what was left out), import_flattened, roots_wrapped, titles_cut, notes_cut and outline_tidied; about the topics, as add_central_topics does, dial_clamped, media_unverified, calendar_utc and theme_for_other_layout; about a template, template_premium and template_newer; and, as create_map does, layout_unsupported, scene_needs_update and theme_unsupported. A premium layout, theme or scene inside the map is left off where your plan does not include it, and the result says how many parts were (gated).

{ "jsonrpc": "2.0", "id": 42, "method": "tools/call",
  "params": { "name": "build_map", "arguments": {
    "title": "Q3 planning",
    "format": "markdown",
    "text": "# Q3 planning\n## Goals\n- Ship the beta\n- Hire two engineers\n## Risks\nBudget is tight this quarter.",
    "drive": "cloud", "folder": "Plans"
  } } }

The reply starts Queued (command <id>). miMind builds "Q3 planning", says how many central topics and nodes and where, and ends Its map_id will be <id>. when every recent device builds it. Structured result: command_id, status, title, map_id (when certain), map_id_certain, source (topics, text or template), format, central_topics, nodes, drive, folder and warnings[]. Once it is built, get_command_status gives the map’s id, and its file name and folder while places are shared.

rename_map write

Queues renaming one map’s file (not its central topic: update_nodes changes that). A device that has the file does it with miMind 26.11.6 or later, while it runs or when it starts; it waits while the map is open on any of your devices with an up-to-date app and sync on. The extension stays, and so does the map_id. A name another file or folder in that folder has, in any letter case, or a change of letter case alone, fails name_taken: nothing is ever replaced. It works only while file places are switched on (until then it answers rename_map is not available at the moment; nothing was queued.), and lapses after 7 days.

It warns place_unknown when where the file is is not known yet (any of your devices with the file may do it), place_device when it is on one device only (only that device can), and map_open while the map is open somewhere. A newer rename_map of the same map replaces one still waiting (and a newer move_map a waiting move). A map someone else shared with you is refused; your own shared maps can be renamed.

{ "jsonrpc": "2.0", "id": 43, "method": "tools/call",
  "params": { "name": "rename_map", "arguments": {
    "map_id": "id_1730450000_9f2c", "name": "Q3 plan (final)"
  } } }

The reply starts Queued (command <id>). miMind renames the file of "Q3 planning" to "Q3 plan (final)". Structured result: command_id, status, map_id, title, name, expires_at and warnings[].

move_map write

Queues moving one map’s file to another folder of the same drive ("" is the drive’s root; a missing folder is created). Done as rename_map is, by a device that has the file, waiting while the map is open; the map_id stays. If that folder already holds a file or folder of the same name it fails name_taken: nothing is ever replaced. To put a map on another drive, duplicate_map it there, then propose_trash_map the original. It works only while file places are switched on, and lapses after 7 days.

It warns as rename_map does: place_unknown, place_device and map_open.

{ "jsonrpc": "2.0", "id": 44, "method": "tools/call",
  "params": { "name": "move_map", "arguments": { "map_id": "id_1730450000_9f2c", "folder": "Archive/2026" } } }

Structured result: command_id, status, map_id, title, folder, expires_at and warnings[].

duplicate_map write

Queues a copy of one map as a new map with its own map_id, in the same folder or another folder or drive: copying to another drive is how a map goes there. One device that has the file and the target drive makes it, with miMind 26.11.6 or later, and publishes the copy at once; get_command_status gives the copy’s id. With a name that is taken it fails name_taken; without one the copy gets the original’s name with “ (2)”, “ (3)” and so on. Maps someone else shared with you are refused (you can Save As in miMind). It lapses after 7 days.

It warns map_id_unknown when some recent device could not make it (the copy’s id comes once it is made), and as rename_map does: place_unknown, place_device and map_open (a copy waits while the map is open too).

{ "jsonrpc": "2.0", "id": 45, "method": "tools/call",
  "params": { "name": "duplicate_map", "arguments": {
    "map_id": "id_1730450000_9f2c", "name": "Q4 planning", "drive": "local"
  } } }

Structured result: command_id, status, map_id (the original’s), new_map_id (when certain), map_id_certain, title, drive, folder and warnings[].

create_folder write

Queues a new folder, and any missing folders above it, on one of your drives; a device with that drive makes it with miMind 26.11.6 or later. A folder that is there already is fine (folder_exists); a file of that name fails name_taken. list_files shows a folder once a map is in it. It lapses after 7 days.

{ "jsonrpc": "2.0", "id": 46, "method": "tools/call",
  "params": { "name": "create_folder", "arguments": { "path": "Clients/Acme", "drive": "cloud" } } }

Structured result: command_id, status, drive, path and warnings[].

rename_folder write

Queues renaming one folder (its last part); the maps in it keep their map_ids. A device with that drive does it with miMind 26.11.6 or later; it waits while any map in the folder is open on one of your devices with an up-to-date app and sync on. It fails excluded_inside when the folder holds a map you hid from agents or encrypted, name_taken when the new name is taken (a change of letter case alone included), and folder_not_found when there is no such folder. It works only while file places are switched on, counts as 5 requests, and lapses after 7 days.

It warns folder_unknown when no published map is known to be in the folder (a device with the drive renames it if it is there), place_device when the folder is on one device only, and map_open while a map in it is open.

{ "jsonrpc": "2.0", "id": 47, "method": "tools/call",
  "params": { "name": "rename_folder", "arguments": { "path": "Clients/Acme", "name": "Acme Corp", "drive": "cloud" } } }

Structured result: command_id, status, drive, path, name, maps_affected (the published maps known to be in it) and warnings[].

add_map_link write

Queues a link card on one node that opens another of your maps, by its map_id, as miMind’s own map links do; the card keeps the target’s id, so it still finds the map after it is renamed or moved, and then opens it in the viewer: the map you have open is neither saved nor closed. In a map you share with others, the card keeps that id only until the map is next saved, and then finds the target where it was. Applied as the edit tools are, the next time the map is open in miMind (at once if it is open now), as one change you can undo, by miMind 26.11.6 or later only. The target map must be on the device that applies it: elsewhere the request fails link_target_not_found and nothing changes.

It warns revision_assumed as the edit tools do, and target_elsewhere when the target’s file is on one device only (only an app there adds the link).

{ "jsonrpc": "2.0", "id": 48, "method": "tools/call",
  "params": { "name": "add_map_link", "arguments": {
    "map_id": "id_1730450000_9f2c", "node": "Budget", "target_map_id": "id_1730460000_4a1b"
  } } }

Structured result: command_id, status, map_id, title, node, node_title, target_map_id, target_title, revision and warnings[].

recover_map write

Queues bringing back a map an approved propose_trash_map moved to the trash in the last 90 days (list_files with in_trash lists them). Only the device that trashed it can, with miMind 26.11.6 or later: the map returns to its folder (or the drive’s root) under its own name, or “<name> (2)” if that is taken, with its map_id, and is published again. A file in that trash whose map id is not this one is never taken for it (not_in_trash). It lapses after 7 days.

It warns place_device with the platform of the device that holds the trashed file. Maps you trashed yourself in miMind are not known to the server: recover those in miMind.

{ "jsonrpc": "2.0", "id": 49, "method": "tools/call",
  "params": { "name": "recover_map", "arguments": { "map_id": "id_1730450000_9f2c" } } }

Structured result: command_id, status, map_id, title, expires_at and warnings[].

list_shared_maps read-only

Lists the maps you share with other people and those others share with you, among those whose copy your miMind app has published (with Sync my maps to the MCP server on), 50 a page, last saved first: your role, the owner’s name, how many people are in it, when it was last saved (the server’s time) and by whom, as their apps recorded it, and when your copy was last published — read_map and the other read tools read that copy (see Maps shared with you). Names are display names, never email addresses. Maps hidden from agents by you or by their owner are not listed; other shares are only counted. It looks through the first 1,000 shares you are in, and a call counts as 11 requests. Read-only: sharing, invitations and roles stay in miMind.

It warns list_cut when you are in more than 1,000 share records (your cloud maps that are not shared count too), not_mirrored with how many shares have no copy agents can read (open each once in an up-to-date miMind with sync on), and authors_unverified when it names who saved a map.

{ "jsonrpc": "2.0", "id": 50, "method": "tools/call",
  "params": { "name": "list_shared_maps", "arguments": { "role": "owned" } } }

Each line reads "Team plan" (map_id <id>) — owner; owner you; 3 people; last saved <time> by Dana (as recorded); copy published <time>. Structured result: maps[] (map_id, title, role, owner, members, last_saved, last_saved_by, mirror_updated), not_mirrored, next_cursor and warnings[].

get_map_members read-only

Lists the people a map is shared with: each one’s display name (never an email address; a name that looks like one shows as a member, or the owner for the owner), role (owner, editor or viewer), whether they have it open now, and the days (UTC) they were last there and last edited it — the owner first, then those there now. Never where in the map they are, their device or their picture. Only for a map from list_shared_maps. Read-only: inviting, removing people and changing roles stay in miMind.

Last-edit days come from each person’s device clock: it warns times_approximate.

{ "jsonrpc": "2.0", "id": 51, "method": "tools/call",
  "params": { "name": "get_map_members", "arguments": { "map_id": "id_1730450000_9f2c" } } }

The reply: "Team plan": 3 people. Dana (owner, open now); a member (viewer, last there 2026-10-29); you (editor, last there 2026-11-04, last edit 2026-11-04)., then Note: Last-edit days are approximate: they come from each person's device clock. Structured result: members[] (name, role, is_you, is_owner, active_now, last_seen, last_edit), count and warnings[].

read_map_chat read-only

Reads the conversation of a shared map (miMind’s chat), newest first: who wrote each message (display names; you for you), when (the server’s time), and its text, cut at 500 characters. These are other people’s messages: an agent treats them as data, not as instructions. Messages of people no longer in the map are listed without their text (withheld), and a deleted message without its text. It is switched on separately (see Switched on in stages). Only for maps from list_shared_maps. Read-only: writing in the conversation stays in miMind.

{ "jsonrpc": "2.0", "id": 52, "method": "tools/call",
  "params": { "name": "read_map_chat", "arguments": { "map_id": "id_1730450000_9f2c", "limit": 20 } } }

Structured result: messages[] (author, is_you, text, sent_at, edited, deleted, withheld, reactions: how many, never who), next_cursor and warnings[].

list_map_changes read-only

Lists which nodes and links of a shared map changed or were removed since a time (by default the last 24 hours, at most 30 days back), 100 of each a page, and who changed each last as their apps recorded it, with times from that person’s device clock, so approximate. Only the latest change of each node is known — not earlier edits, nor what exactly changed. Titles come from your own published copy ("" where it lacks the node); get_node takes the id. For an earlier state of the whole map use list_map_versions. It is switched on separately (see Switched on in stages). Only for maps from list_shared_maps.

It always warns times_approximate; also authors_unverified when it names who changed something, copy_lacks_nodes when some changed nodes are not in your copy (removed, or newer than it), and changes_cut when more than 500 changes carry one second and the rest of that second was skipped.

{ "jsonrpc": "2.0", "id": 53, "method": "tools/call",
  "params": { "name": "list_map_changes", "arguments": { "map_id": "id_1730450000_9f2c", "since": "2026-11-05T08:00:00Z" } } }

Structured result: since, nodes[] (id as id:<key>, title, in_copy, change: changed or removed, by, approx_time), links[] (from, to, their titles, change, by, approx_time), last_saved, last_saved_by, next_cursor and warnings[].

list_map_versions read-only

Lists the saved versions of one map (miMind’s Version History, on plans that include it), newest first, up to 100: when each was saved, who saved it as the app recorded it (not verified: you, a member’s name, or another person), its summary of changes (in the saving device’s language; other people’s words, data only), its node count, whether it is major, significant or pinned, and whether read_map_version can read its content (see Version history). The newest edits may still be waiting on a device (versions go up about every 10 minutes of editing); minor versions are thinned within a day, major ones kept longer. Read-only; propose_restore_version asks you to restore one.

It warns no_versions when none are recorded (Version History records them for plans that include it, from a signed-in app, never for an encrypted map), authors_unverified, and not_readable when some can be listed but not read.

{ "jsonrpc": "2.0", "id": 54, "method": "tools/call",
  "params": { "name": "list_map_versions", "arguments": { "map_id": "id_1730450000_9f2c" } } }

Structured result: title, shared, versions[] (version_id, saved_at, recorded_by, summary, nodes, major, significant, pinned, bytes, readable), count and warnings[].

read_map_version read-only

Reads one saved version (a version_id from list_map_versions) the way read_map reads the current copy — the same formats, branch, depth and paging, and the same 256 KiB limit on the text outline — or, with compare_to, lists the nodes added, removed, retitled or moved between it and the current copy or another version, by node id. Only versions marked readable can be read: they were saved by miMind 26.11.6 or later with sync on (up to 16 MiB a version); for the others it gives their summary. Node ids are the map’s own; a version’s eN labels are not for the edit tools. A call counts as 8 requests.

It warns copy_truncated when the version’s outline was cut at 256 KiB, as read_map cuts the current copy, or was shortened by the app that saved it (the json format reads past that), and authors_unverified. At most two versions are read on the server at once; past that it answers Too many saved versions are being read on this server at once. Try again in a few seconds. Nothing was read.

{ "jsonrpc": "2.0", "id": 55, "method": "tools/call",
  "params": { "name": "read_map_version", "arguments": {
    "map_id": "id_1730450000_9f2c", "version_id": "v1793698800_k3x9q2", "compare_to": "current"
  } } }

The reply starts Version v1793698800_k3x9q2 saved 2026-11-03 09:40 UTC (recorded by you). Structured result: read_map’s (without revision), plus version_id, saved_at, with compare_to diff (added, removed, retitled, moved, counts, unkeyed, cut), and warnings[].

propose_restore_version write

Asks you to approve restoring one saved version of a map. Nothing changes when the agent calls it: the request waits in that map’s Agent Requests, and only when you approve it there, with the map open, does miMind first keep the current map as a version in Version History, then replace the map’s nodes and its look (canvas colour, wash, theme, scene, line flow, glow, grid) with the version’s. Undo in miMind brings the nodes back but not that look; the kept version has both. Unapproved, it lapses after 14 days. It needs miMind 26.11.6 or later; earlier versions list it as a request they cannot show, which you can reject there.

Refused, and nothing queued, for a map that is not published, hidden from agents, encrypted or someone else’s; for a map you share with others (restore it yourself from Version History); for a version that is not listed; and while another request to restore the same map waits. When you approve it, the app checks again: on a device that records no versions it refuses, and nothing changes. The reply warns minor_version (minor versions are thinned within a day: the request fails if the version is gone when you approve it) and map_open while the map is open on one of your devices.

{ "jsonrpc": "2.0", "id": 56, "method": "tools/call",
  "params": { "name": "propose_restore_version", "arguments": {
    "map_id": "id_1730450000_9f2c", "version_id": "v1793698800_k3x9q2",
    "reason": "Today's edits dropped the budget branch."
  } } }

The reply: Queued (command <id>) for the user's approval in miMind: restore "Launch plan" to the version from 2026-11-03 09:40 UTC. Nothing changes until the user approves it with the map open; it lapses unapproved after 14 days. Follow it with get_command_status. Structured result: command_id, map_id, title, version_id, version_saved_at, status (pending), expires_at and warnings[]. Once restored, get_command_status says so (code restored; see What a restore ended with).

export_map read-only

Exports one map from the copy your miMind app published, as read_map reads it, in a format read_map does not have: freemind (a .mm file FreeMind, Freeplane and other mind-map apps open, with each node’s note, colours, folding and id), html (a plain web page of the outline: titles, notes and, once rich content is on, tables, lists and check boxes; every text escaped, no script, nothing loaded from elsewhere, links only to http and https addresses), tree (nested JSON [{title, note, children}] that build_map takes back as json) or csv (one row per node in read_map’s columns; a field that starts like a spreadsheet formula — =, +, -, @, a tab or a line break, or the full-width forms of the four — gets a leading ', so a spreadsheet shows it as text). A long map comes in pages of whole nodes, each a complete file: the CSV header line is on every page, and a FreeMind page that holds several top nodes puts them under one root named after the map. Links that open another of your maps (map-link cards and miMind links) are left out of every export, and such a link written in a title, a note or a cell reads (a link to a map): get_map_links and get_node_content name the maps agents can read. Nothing is saved; export_map_file saves a file on your device (see Exports).

The reply’s text is a head line, a blank line and the page itself, then, when more pages follow, how to ask for the next one and any notes; the data gives the page’s length (chars), never its text again. It warns outline_only (no full copy: exported from the text outline, with one-line notes and no ids, styles or content), copy_truncated, freemind_root_added, tree_reimport (build_map leaves out web addresses and paths when it imports), csv_prefixed, node_cut (in html, a node whose content is longer than one page keeps what fits), max_chars_low (each page holds one node: ask for more) and charged. A call counts as 2 requests, and one more for every 50,000 characters past the first 50,000.

{ "jsonrpc": "2.0", "id": 57, "method": "tools/call",
  "params": { "name": "export_map", "arguments": { "map_id": "id_1730450000_9f2c", "format": "freemind" } } }

The reply starts Export of "Launch plan" (map_id: id_1730450000_9f2c) as a FreeMind file, from the full copy: nodes 1-48 of 48. Structured result: map_id, title, format, mime_type, filename, chars, offset, next_offset, nodes, total_nodes, source (detail or outline), truncated, revision and warnings[].

export_events read-only

Lists the dated nodes (timeline dates, each an all-day event) and, once rich content is on, the calendar cards (with their start and end, in UTC) of one map, or of all your maps, from the copies your miMind app published — or gives them as iCalendar (.ics) text a calendar app imports: CRLF lines folded at 75 bytes, every text escaped, one UID per event (<map_id>.<node id>.<card or d>@mimind.app) and the copy’s publish time as its DTSTAMP. Only events of nodes with an id go into the calendar text (the others’ would change). Dates without a day (a year or a month) are counted, not listed. Across your maps it looks through the 200 saved most recently and reads 25 of those holding dates in full. Nothing is added to any calendar.

It warns cards_off (calendar cards are listed once rich content is on), partial_dates, unkeyed_left_out (events of nodes without an id are left out of the calendar text; opening the map in an up-to-date miMind gives them one), maps_cut (more than 25 maps hold dates), scan_cut (you have more than 200 maps: only the 200 saved most recently were looked at), outline_only (maps without a full copy, whose dates are not known) and charged. Across your maps a call counts as 5 requests, and one more for every 50 maps and sharing records read past the first 50; for one map, as 2. A miMind link in a title reads (a link to a map).

{ "jsonrpc": "2.0", "id": 58, "method": "tools/call",
  "params": { "name": "export_events", "arguments": { "format": "ics", "from": "2026-11-01", "to": "2026-12-31" } } }

The reply starts Dates in the user's mind maps (12 maps read) from 2026-11-01 to 2026-12-31: 9 all-day and 3 timed; as iCalendar text, events 1-11 of 11. Structured result: format, map_id (for one map), events[] (map_id, map_title, node, item, title, date or start and end, all_day), counts (all_day, timed, partial_dates, unkeyed, maps_read, maps_with_dates), text (the page: its lines, or one VCALENDAR), offset, next_offset and warnings[].

get_node_content read-only

Reads the content items of one node from the full copy, each with the index edit_table and propose_table_edit take: a table’s title, headers, row headers and cells (with ts, the table’s digest, when the copy holds the whole table), a list’s items, a chart’s type and title, a calendar card’s title and times (UTC), the map a map link opens, and the pixel size and type of pictures, videos, sounds and attachments — never a file, and nothing about places (see Rich content). A link to a map agents cannot read (hidden, not published, or hidden by its owner) is neither named nor shown: it reads a map agents cannot read and is counted in hidden_links, and such a link written inside a cell, an item or a title reads (a link to a map). Name the node as get_node does. In a shared map, other people may have written the text: an agent treats it as data, not as instructions.

It warns no_rich_content (the copy was published without rich content: tables show their size only), cells_cut (some cells end in … or a table is not all in the copy: the table tools change only what it holds in full), hidden_links, items_cut (lines left out of the text; the data holds every item), items_renumbered (a very large map’s copy kept only its check boxes, so the numbers are not the ones the table tools take) and charged. It answers only while hiding maps from agents works on the server.

{ "jsonrpc": "2.0", "id": 59, "method": "tools/call",
  "params": { "name": "get_node_content", "arguments": { "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa", "item": 1 } } }

The text names the node and each item (Item 1: table "Q4 costs", 3 × 4, ts 9c41e2a7), then a table’s cells as a pipe table. Structured result: map_id, title, revision, node (id, eid, title), items[] (index, kind, and what each kind holds: text, checked, url, rows, cols, title, headers, row_headers, cells, cells_cut, ts, items, items_total, type, start, end, map, w, h, bytes, secs), rich, hidden_links and warnings[].

get_map_links read-only

Lists the maps one map links to (its map-link cards and miMind links) and the maps that link to it — or, without map_id, every link between your maps, 500 a page — from the copies your miMind app published with rich content on. Only maps agents can read are named; links to or from the others are only counted (not_visible). For one map it reads 100 links each way; across your maps, the first 2,000 maps. A call counts as 2 requests, and one more for every 50 maps and sharing records read past the first 50. Read-only: add_map_link adds a link.

It always warns links_partial (links are known only in copies an up-to-date app published with rich content on), and links_unknown (this map’s copy holds no list of links), in_cut (more than 100 maps link to it), scan_cut (you have more than 2,000 maps; links to maps past them are counted in not_scanned), links_cut (more than 20,000 links) and charged. It answers only while hiding maps from agents works on the server.

{ "jsonrpc": "2.0", "id": 60, "method": "tools/call",
  "params": { "name": "get_map_links", "arguments": { "map_id": "id_1730450000_9f2c" } } }

Structured result: map_id, title, links_out[] and links_in[] (map_id, title), without map_id edges[] (from, to) and maps_scanned, not_visible, not_scanned, next_cursor and warnings[].

get_map_thumbnail read-only

Returns the small picture of one map your miMind app published with its copy (a JPEG of at most 256 pixels on its longer side), as an image the agent sees: the map’s look and, at low resolution, the pictures in it (see Map pictures). The app pictures a map when you close it or save it from its menu; a map changed since has none until it is closed again, and then the reply says so (has_thumbnail false; not an error). A call counts as 2 requests. It answers only while hiding maps from agents works on the server.

It warns thumb_unreadable when the stored picture cannot be read (the next publish replaces it).

{ "jsonrpc": "2.0", "id": 61, "method": "tools/call",
  "params": { "name": "get_map_thumbnail", "arguments": { "map_id": "id_1730450000_9f2c" } } }

The reply: Thumbnail of "Launch plan" (256 × 171, 18 KB, published 2026-11-05 14:03 UTC). and the picture as an MCP image block (image/jpeg). Structured result: map_id, title, has_thumbnail, width, height, bytes, updated and warnings[] — never the picture itself.

edit_table write

Queues additions to a table on a node, applied the next time the map is open in an up-to-date miMind, as one change you can undo: text for cells and column headers that are empty in the copy, rows at the bottom and columns at the right. It never changes or clears a cell that has text, nor removes anything: propose_table_edit asks you for that (see Tables). Name the node as the edit tools do and the table by its index from get_node_content. Filling cells or headers, and new columns that put text into existing rows, need the whole table in the copy, and the app then does nothing if the table changed in any way since the copy (sorted, a row or a column moved, a cell, a header or its title edited): the request fails target_changed. New rows alone are added whatever happened. Text is one line: line breaks, tabs and runs of spaces (the Unicode spaces too) become one space.

Refused, and nothing queued, when the item is not a table, the copy holds only the table’s size (published without rich content) or not the whole table (cells_cut), a cell or header to fill has text, or the table would pass 100 rows, 20 columns or 2,000 cells. The reply warns revision_assumed and rows_padded (a new row has fewer cells than the table’s columns). It needs miMind 26.11.6 or later; earlier versions leave it waiting until it lapses after 30 days. Once applied, get_command_status says so (code table_edited; see What a table request ended with).

{ "jsonrpc": "2.0", "id": 62, "method": "tools/call",
  "params": { "name": "edit_table", "arguments": {
    "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa", "item": 1,
    "fill": [ { "row": 2, "col": 3, "text": "Done" } ],
    "add_rows": [ [ "Launch party", "Dana", "2026-12-01" ] ]
  } } }

Structured result: command_id, map_id, title, status (pending), revision, node (eid, id, title), item, cells, headers, rows_added, cols_added, expires_at and warnings[].

propose_table_edit write

Asks you to approve, in the map’s Agent Requests, changes to a table on a node: new text for up to 50 cells and column headers that have text ("" clears one), a new title, and removing rows or columns. Nothing changes until you approve it with the map open; the card lists every change with the text before and after, read from the table as it is then. The request is bound to the whole table as the copy holds it (its digest ts, which get_node_content gives), so it needs the whole table in the copy — removals and a new title too — and if the table changed in any way before you approve (sorted, a row or a column moved, a cell, a header or its title edited), the card says The table changed since the agent asked for this. and offers Reject only. Unapproved, it lapses after 14 days. One request a table waits at a time. Text is one line, as for edit_table.

Refused, and nothing queued, when the item is not a table, the copy does not hold the whole table (cells_cut), every text given is already there (Nothing would change), a removal would take every row or column, or another request to change the same table waits. A request an earlier miMind cannot show waits until it lapses. Once approved and applied, get_command_status says so (code table_changed).

{ "jsonrpc": "2.0", "id": 63, "method": "tools/call",
  "params": { "name": "propose_table_edit", "arguments": {
    "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa", "item": 1,
    "set": [ { "row": 0, "col": 2, "text": "1,200" } ], "remove_columns": [ 3 ],
    "reason": "The invoice says 1,200 and the Notes column is empty.", "ts": "9c41e2a7"
  } } }

The reply lists each change (- Cell (row 0, column 2): "900" -> "1,200") and says nothing changes until you approve it with the map open. Structured result: command_id, map_id, title, status (pending), revision, item, cells, headers, title_changed, rows_removed, cols_removed, ts, changes[] (what, row, col, before, after, summary), expires_at and warnings[].

export_map_file write

Asks your miMind app to export one map as a file on your device, as its Export menu does: docx (Word, with the map’s pictures), svg (the map drawn as a vector picture), markdown, opml or txt. A device that has the map does it the next time miMind runs there with sync on, from the map as last saved (your unsaved changes are not in it), and saves it as a new file in miMind’s exports folder there — Documents/miMind Exports on Windows and Linux, miMind/Exports in the Files app on iPhone and iPad — or in the subfolder folder names in it, never over a file that is there: the map’s title as the name gets (2), (3)… when it is taken, and a name you give that is taken fails (name_taken). The file is not shown in miMind’s map lists: open it from that folder. It never goes to miMind Cloud, iCloud, Google Drive, Dropbox or OneDrive, and the Mac app (until you can pick the folder), the Android app, the Windows Store app and the web app make no agent exports: any drive but local answers drive_unsupported, and the file is never put somewhere else instead. Nothing of it reaches our server or the agent, which learns the format, the size (and for Word the number of pictures) and, while file places are shared, where it went (see Exports). At most 20 a day, 25 MiB each; the formats follow your plan, as in the Export menu. Maps others shared with you are refused (export them yourself in miMind), as are maps you hid from agents and encrypted maps. It lapses after 7 days, and a call counts as 10 requests.

Refused, and nothing queued, past the day’s 20 (The user's daily limit of 20 exports is reached; it resets at midnight UTC.) and while another request to export the same map in the same format waits. It needs miMind 26.11.6 or later; earlier versions never get it. Once done, get_command_status says exported, with the size (see What an export ended with).

{ "jsonrpc": "2.0", "id": 64, "method": "tools/call",
  "params": { "name": "export_map_file", "arguments": { "map_id": "id_1730450000_9f2c", "format": "docx" } } }

Structured result: command_id, map_id, format, status (pending), expires_at and warnings[].

request_map_copies write

Asks one of your devices to publish the copies agents read for the maps in one folder of a drive (not its subfolders) — or one named map file there — that have no copy yet: maps you have not opened since you turned sync on. A device with that drive does it the next time miMind runs there with sync on, one map at a time, at least 2 seconds apart and at most 10 minutes of work a run, up to 50 a request. It first asks our server which of them already have a copy (published by any of your devices) and loads none of those; it never replaces another device’s copy, and skips maps you hid from agents on that device and encrypted maps. The result gives counts only, and the MCP Server dialog shows that it ran (An AI agent published copies of <n> maps on <date>.). At most 5 a day; it lapses after 7 days, and a call counts as 10 requests.

Refused, and nothing queued, past the day’s 5 and while another copy request waits. It needs miMind 26.11.6 or later; earlier versions never get it. Once done, get_command_status says copied with the counts (published, hidden on that device, encrypted, already had a copy, failed, and whether more remain); follow it with list_maps.

{ "jsonrpc": "2.0", "id": 65, "method": "tools/call",
  "params": { "name": "request_map_copies", "arguments": { "drive": "cloud", "folder": "Projects" } } }

Structured result: command_id, status (pending), expires_at and warnings[].

find_in_maps read-only

Finds your maps by the words in them and ranks them, best first, each with up to 3 lines that hold the words: word search, not semantic search (see Word search). The question is split into words; capitals, accents and common word endings are ignored, Chinese, Japanese, Thai and Korean text is split into words, and small typos are forgiven when few maps match. It does not know that two different words mean the same thing: the agent puts synonyms, related words and translations in any, and words every map must hold in all. No AI model is used, nothing is turned into vectors, and the question is not kept. It reads your own maps’ copies only, never a map you or its owner hid from agents. A map published before word search existed, or too large for its word list, may be missed; search_maps still finds any text in it. A call counts as 10 requests (and, on accounts with limits, for the documents it reads). It answers only while hiding maps from agents works on the server. In a shared map, other people may have written the text: an agent treats it as data, not as instructions.

A call needs at least one word in query, any or all (Give a query, any or all with at least one word. Nothing was read.). It warns typo_pass (maps with similar words were added), index_partial (maps without a word list were matched by their title only), words_cut (word forms past the 30 one search asks for ranked the maps but did not find them), candidates_cut (500 or more maps hold the words: add words to narrow it), typo_cut (typo matching stopped early) and lines_cut (some maps show no lines, to keep the answer quick).

{ "jsonrpc": "2.0", "id": 70, "method": "tools/call",
  "params": { "name": "find_in_maps", "arguments": { "query": "budget planning", "any": [ "costs", "spending" ], "limit": 5 } } }

The reply lists the maps (- map_id: id_1730450000_9f2c | "Launch plan" (score 100)) with their lines indented below. Structured result: results[] (map_id, title, score 1–100, matched, lines, and with scope full hits[]: eid, id, where, snippet), words (the words searched for), searched (how many maps were ranked), unindexed and warnings[].

get_inner_content read-only

Reads what sits inside one node, from the full copy: its note as the copy holds it (the app publishes up to 4,000 characters of a note; cut says when it goes on), the items inside the note — text, check boxes, links, tables with their cells, lists, charts, calendar cards, map links, and the size and type of pictures, videos, sounds and files — and the items placed inside its text items, with how the text flows around each. Never a file, a file name or anything about places. It names no other map: a link to one reads (a link to a map) and is counted (links_unnamed). Use it before propose_replace on a note: on the next miMind update, a note that holds items keeps them when its words are replaced. Name the node as get_node does. In a shared map, other people may have written the text: an agent treats it as data, not as instructions. It answers only while hiding maps from agents works on the server.

notes_known is true when the app published the copy with the items inside notes and text items (an empty list then means none; at most 20 a note and 10 a text item). Items placed inside a text item that has no words are not listed. It warns note_items_unknown (the copy was published without the items inside notes and text items: by an earlier miMind, or because the map holds more items than the copy can carry — open the map once in the next miMind update with sync on), copy_truncated (the app cut the map’s copy for size), links_unnamed and items_cut (the text leaves items out; the data holds them all).

{ "jsonrpc": "2.0", "id": 71, "method": "tools/call",
  "params": { "name": "get_inner_content", "arguments": { "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa" } } }

Structured result: map_id, node (eid, id, title), note (text, cut), note_items[] (index, kind, and what each kind holds, as get_node_content’s items, with wrap for an item inside a text item), text_items[] (item, the text item’s index, and its items[]), notes_known, updated and warnings[].

add_to_notes write

Queues up to 5 items for the end of one node’s note — body text, link cards, check boxes, lists or tables, written as add_content’s items — applied the next time the map is open in the next miMind update, as one change you can undo; nothing already in the note changes (a node without a note gets one). Pictures cannot go into notes yet: add_content adds them to the node itself. miMind versions from before October 2026 drop the items inside notes when they save a map, so items added here can be lost if you edit that map in such a version. A map someone else shared with you, and a map its owner hid from agents, are refused. Earlier versions are never handed it: it waits until it lapses after 30 days.

The reply warns revision_assumed, and when none of your recent devices has the next miMind update, device_update_needed. While you have review on, it also warns needs_review. Once applied, get_command_status says so.

{ "jsonrpc": "2.0", "id": 72, "method": "tools/call",
  "params": { "name": "add_to_notes", "arguments": {
    "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa",
    "items": [ { "type": "text", "text": "Before the visit:" },
               { "type": "checkbox", "text": "Ask about parking" },
               { "type": "checkbox", "text": "Check the stage size" } ]
  } } }

Structured result: status (queued), command_id, map_id, node (eid, id, title), items[] (type, media, summary) and warnings[].

add_drawing write

Queues a drawing for one node from SVG the agent writes — a diagram, an icon, a simple chart, a sketch — which the next miMind update checks again, turns into a picture on the node and applies the next time the map is open, as one change you can undo (see Agent drawings). Our server keeps only what the rules allow and queues its own clean copy, at most 64 KiB, 4,000 elements and 32 levels, with a viewBox or a width and height; the reply says what it left out or reduced. Refused, and nothing queued: scripts, styles, embedded or linked images, foreign objects, links, animation, filters, DOCTYPE and entities, any reference outside the SVG (The SVG was refused (<code>: <detail>). Nothing was queued.), and a drawing with too much to draw (The drawing has too much to draw. Nothing was queued.). At most 50 drawings a day for your account (The user's daily limit of 50 drawings is reached; it resets at midnight UTC.). Earlier versions are never handed it: it waits until it lapses after 30 days.

The reply warns svg_dropped and svg_clamped (what the clean copy leaves out or reduces), svg_text (the drawing holds text, which draws only where the device has the fonts: prefer paths), revision_assumed, and, while you have review on, needs_review. Once applied, get_command_status says so; a drawing the app could not check or draw fails (see What a Phase 13 request ended with).

{ "jsonrpc": "2.0", "id": 73, "method": "tools/call",
  "params": { "name": "add_drawing", "arguments": {
    "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa", "caption": "Launch stages",
    "svg": "<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 300 80\"><rect x=\"5\" y=\"20\" width=\"80\" height=\"40\" rx=\"8\" fill=\"#5b8cff\"/><rect x=\"110\" y=\"20\" width=\"80\" height=\"40\" rx=\"8\" fill=\"#7c5cff\"/><rect x=\"215\" y=\"20\" width=\"80\" height=\"40\" rx=\"8\" fill=\"#e8b84a\"/><path d=\"M85 40H110M190 40H215\" stroke=\"#333\" stroke-width=\"3\"/></svg>"
  } } }

Structured result: status (queued), command_id, map_id, node (eid, id, title), width and height (the clean copy’s, its longer side 1,024), bytes, dropped[], clamped[] and warnings[].

reorder_content write

Queues moving one content item of a node — a picture, text, link card, table and so on, numbered as get_node and get_node_content number them — to another place in that node’s order, applied the next time the map is open in the next miMind update, as one change you can undo. Nothing is removed or rewritten. The item is named by its index, its kind and, for an item with text, its text as read: if the copy’s item says otherwise, the call is refused (Item <i> of "<node>" in the copy is …, not …. Read it again with get_node. Nothing was queued.), and if it changed before the app applies it, the request fails item_changed. The node’s title and the boxes of a check-box or radio-button group cannot be moved (the app refuses a group’s box). Earlier versions are never handed it: it waits until it lapses after 30 days.

Refused, and nothing queued, when the item is already there. The reply warns revision_assumed. While you have review on, it also warns needs_review.

{ "jsonrpc": "2.0", "id": 74, "method": "tools/call",
  "params": { "name": "reorder_content", "arguments": { "map_id": "id_1730450000_9f2c", "node": "id:n4k2m9qa", "item": 1, "kind": "table", "to": "first" } } }

Structured result: command_id, map_id, title, status (pending), revision, node (eid, id, title), item, kind, to, expires_at and warnings[].

set_scene write

Queues the animated scene behind a map: one of your own saved scenes (the Yours scenes, by the id list_catalog kind my_scenes gives), or a new scene the agent writes as scene JSON, in the format list_catalog kind scene_format describes. The next miMind update checks and tidies a new scene before it shows it, keeping it readable behind the map, so what shows may differ from what was written; it applies it the next time the map is open, as one change you can undo, and saves nothing to your scene library. The built-in scenes and none are set with set_map_style. A saved scene is applied by a device that has it (else the request fails scene_unknown); a new scene that leaves nothing to show fails scene_invalid. Earlier versions are never handed it: it waits until it lapses after 30 days.

Refused, and nothing queued, for a saved id that is not in your library (No saved scene "<id>". list_catalog kind my_scenes lists them. Nothing was queued.) and for both or neither of saved and scene. The reply warns dial_clamped when a dial was out of range. While you have review on, it also warns needs_review.

{ "jsonrpc": "2.0", "id": 75, "method": "tools/call",
  "params": { "name": "set_scene", "arguments": { "map_id": "id_1730450000_9f2c", "saved": "s0f3a9c27d1e44b6b8a5c2e19d7f60a3b", "animate": true, "strength": 0.6 } } }

Structured result: command_id, map_id, title, status (pending), revision, scene (source saved or json, saved, json_chars), expires_at and warnings[].

set_title_list write

Queues turning one node’s title into a short list of 2 to 20 lines with markers our server writes: bullet (•), number (1. 2. 3.), roman (I. II. III.), alpha (A. B. C.) or check (☐ open and ☒ done boxes), applied the next time the map is open in the next miMind update as a rename you can undo. The lines replace the title; read_map shows them joined on one line. A marker the agent typed at a line’s start is removed only when it is exactly the one the list writes there; anything else stays as text. For anything longer than a short list, child nodes are usually better. Earlier versions are never handed it: it waits until it lapses after 30 days.

The reply warns revision_assumed. While you have review on, it also warns needs_review. A title whose lines no longer start with the list’s markers when the app applies it fails list_invalid.

{ "jsonrpc": "2.0", "id": 76, "method": "tools/call",
  "params": { "name": "set_title_list", "arguments": { "map_id": "id_1730450000_9f2c", "node": "Packing", "list": "check", "lines": [ "Passport", "Charger", "Tickets" ], "checked": [ 0 ] } } }

Structured result: command_id, map_id, title, status (pending), revision, node (eid, id, title), list, lines, new_title, expires_at and warnings[].

ChatGPT’s search and deep research look for a server’s search and fetch. A connection made from ChatGPT lists both right after the first twenty-five, before the four that ask for your approval or leave you a message (propose_delete, propose_replace, revert_command and post_suggestion, and the file tools after them); a token, claude.ai and Claude Code never see them (a token calling one gets Unknown tool). Both only read, through search_maps and read_map, and need the same plan as the other tools.

No citation links yet. Each result’s url is empty, because no web address opens a given map yet: ChatGPT shows the result without a link. It will carry one when such a link exists. From miMind 26.11.6, once map links are switched on, it is https://mimind.app/open?map=<map_id>, which opens the map in miMind on a device that has it (see Map links).

search read-only

Finds your published maps whose title or text matches the query, for search and deep research: the first 25 maps search_maps finds, each with an id to pass to fetch, its title and a url. A call counts as 5 requests, like search_maps; for the matching lines inside maps, an agent uses search_maps itself.

{"results":[{"id":"map:id_1730450000_9f2c","title":"Product Roadmap","url":""}]}

The result’s text is that JSON as a string, and structuredContent the same object.

fetch read-only

Returns one map’s text outline by the id a search result gave, as read_map reads it (its first page).

{"id":"map:id_1730450000_9f2c","title":"Product Roadmap","text":"e0 Product Roadmap\n  e1 Q3 …","url":"","metadata":{"node_count":42,"total_lines":42,"truncated":false}}

The result’s text is that JSON as a string, and structuredContent the same object. An unknown id answers as read_map does.

A chat app that draws views — claude.ai, with Claude Desktop and Claude’s mobile apps, connected by signing in — can show one of your maps as an interactive picture inside the conversation with show_map. An app that asks for the newest protocol revision also gets four ready-made prompts. Neither calls a model on our side, and neither changes anything.

show_map read-only

Shows one of your maps as an interactive, read-only picture in the chat: its topics as a tree (or an outline) you can fold, pan and zoom, with a topic’s note on a tap. It is drawn from the copy your miMind app published, as read_map reads it, and shows text only — no pictures, files or links from the map. A large map shows its first 2,000 topics; read_map reads the rest. Nothing changes: the edit tools change the map. A call counts as 2 against the rate limits.

Where the chat draws views

• Only there. show_map is listed, last after the tools, only on a connection whose app draws views: claude.ai (with Claude Desktop and Claude’s mobile apps), connected by signing in. A token, Claude Code and a ChatGPT connection never list it (ChatGPT may follow after a check of its own), and a call from them answers Unknown tool: show_map, as before.
• On a recent protocol revision. The app must speak revision 2025-06-18 or later and, unless we widen it, ask for 2025-11-25 (see Protocol Details).
• Elsewhere, an outline. Where the chat cannot show the view, the answer is a short text outline of the same topics.

The view shows each topic’s title (up to 120 characters) and the start of its note (up to 200), keeps folded the topics you keep folded in miMind, and marks topics with content it does not show. Tap or click a topic to read its note; fold and unfold branches; drag to pan; zoom with the wheel or a pinch; switch between a tree and an outline, or to full screen. It follows the chat’s light or dark theme. Once map links are switched on, Open in miMind opens the map in the app. A map you hid from agents, or whose owner hid it, is not found, as with read_map.

The page that draws it comes from our server and holds none of your data: it loads nothing from anywhere else, calls no tool, stores nothing and cannot change your map, and the chat app shows it in a sandboxed frame inside the conversation.

The structured result has map_id, title, app, mode (tree), updated, source, total_nodes, shown_nodes, truncated, copy_truncated, url, nodes (rows [parent, title, note, flags]) and warnings (outline_only, copy_truncated, view_cut).

Prompts

Four ready-made prompts start common tasks, where an app offers prompts (in Claude Code, for example, as /mcp__mimind__summarize_map). Each is fixed text that tells the agent which tools to use: our server reads nothing for it, calls no model and keeps nothing, and the agent then uses the tools as it would anyway. An app gets them only when it asks for the newest protocol revision, 2025-11-25; a read-only token or connection gets the first two.

A map or title is one line of at most 200 characters, and notes at most 20,000; longer text is cut. An unknown prompt answers Unknown prompt., a missing argument Missing argument: <name>.

Agents never modify your data directly. create_map, add_nodes, set_background, insert_nodes, update_nodes, move_nodes, add_content, set_map_style, add_central_topics, connect_nodes, format_nodes, set_node_state, copy_nodes and refine_map_style place a request in a queue of your own; your miMind app builds the map, adds, changes, moves or copies the nodes, adds their content, formats them, ticks their check boxes or folds their branches, links them or restyles their lines, or sets the scene, with the same engine as the built-in AI assistant, as changes you can undo. These requests delete and replace nothing: none removes a node, a line, a label or an animation, overwrites a note or changes content a node already has. Adding content and adding to the end of a note are the only changes to what a node holds; renaming, restyling, formatting, dating, ticking and moving change only the nodes themselves, and giving nodes back the style sheet’s defaults or the theme’s styling discards their hand-set look as one step you can undo. Deleting and replacing come only as requests for your approval (propose_delete, propose_replace, revert_command), which miMind applies only after you approve each one in the map’s Agent Requests. File requests (build_map, rename_map, move_map, duplicate_map, create_folder, rename_folder and recover_map) are queued the same way, for your app on a device that has the file, and so is add_map_link, for when the map is open; none deletes or replaces a file or a folder, and a map leaves only through the trash, when you approve propose_trash_map. propose_restore_version only asks as well: a version is restored only when you approve it (see Restoring a version).

• create_map — built when miMind starts or you sign in, on a device with sync on, with the layout and scene it asked for; from miMind 26.11.6 also while miMind is running (see Live delivery). The new map lands in your active folder (and uploads if that folder is cloud-synced). One device builds it: the device that picks it up holds it for 10 minutes, so another device or a second sign-in does not build it again; should that device stop halfway, another builds it after those minutes.
• add_nodes and set_background — applied when you next open that map in the main editor with autosave on, or, from miMind 26.11.6, at once while it is open there (see Live delivery). From miMind 26.11.6, a map open in view or presentation mode waits until you switch to editing, a request is never applied twice, and a premium layout’s branch you have no subscription for fails instead of showing an upgrade prompt. Only the newest set_background for a map waits.
• insert_nodes, update_nodes and move_nodes — applied in the same way, by miMind 26.11.6 or later only, all of a request or none of it (see Editing nodes). Older versions leave them waiting until they lapse.
• add_content — applied in the same way, by miMind 26.11.6 or later only, all of a request or none of it, after what each node already has. Pictures are placed as tiles at once and downloaded afterwards (see add_content).
• set_map_style and add_central_topics — applied in the same way, by miMind 26.11.6 or later only, all of a request or none of it. While you have the style sheet, a theme or a scene preview open, they wait until you close it (so does set_background).
• connect_nodes — applied in the same way, by miMind 26.11.6 or later only, all of a request or none of it. Adding an animation needs the connection animations of your plan; without them the request fails (premium_animation) and nothing changes.
• format_nodes, set_node_state, copy_nodes and refine_map_style — applied in the same way, by miMind 26.11.6 or later only, all of a request or none of it. Formatting, copying, spacing or restyling inside a branch arranged by a premium layout you have no subscription for fails (premium_layout) and nothing changes; fonts, shapes, numbering, grouping, check boxes, folding and copies need no subscription. A focus selects the node and scrolls it into view: it is the only request that moves your view, and it is no undo step. Folding is your device’s own view: it is not shared with the people you share a map with.
• Live delivery — from miMind 26.11.6, the desktop and mobile apps apply a request at once while the map is open, as soon as you are not busy with it: while you type a title or a note, drag a node, or have the style sheet, a line, font or colour panel, a menu or the chat at work, the request waits and is applied when you finish. Your view stays where it is, the banner below says what changed, and a new map from create_map appears in your list without a restart. It works while you are signed in with sync on; the web app and the Windows Store app apply requests when you open the map or start the app, as before. A live apply publishes a new copy, so the map’s revision changes: an agent reads the map again, or names nodes by id:.
• One step each, and a banner — from miMind 26.11.6, each request is one step in the map’s undo history, a new look, new central topics, formatting, folding and copies included (a focus is no step): Undo (or its shortcut) takes back one request at a time, and Redo brings it back. When requests were applied as you opened the map, or while you had it open, a banner says An AI agent changed this map., with Undo, which takes back every request applied since the banner appeared, and OK. It stays until you choose one, change the map yourself, or leave the map.
• propose_delete, propose_replace and revert_command — never applied on their own: they wait for your answer in the map’s Agent Requests, and one you approve is applied at once, all of it or none, as one change you can undo. post_suggestion changes nothing: it leaves you a message there.
• File requests — build_map, rename_map, move_map, duplicate_map, create_folder, rename_folder and recover_map are done by miMind 26.11.6 or later only, by one device that has the file (or the drive) and sync on, while miMind runs there (at once where live delivery works) or when it starts or you sign in. A map on This Device is done only by that device, and recover_map only by the device that trashed the map; a cloud map that is not downloaded on a device waits for one that has it. A request on a map waits while the map is open on any of your devices with an up-to-date app and sync on (a folder rename while any map in the folder is), and goes ahead soon after you close it there. A device takes up to three at a time and holds each for 10 minutes, so no other device does it meanwhile. A request no device can do is never failed for that: it waits until it lapses, and once every device of yours that synced recently has said it does not have the file or the drive, it lapses within 48 hours.
• build_map — the first device that picks it up builds it, once: before building, it looks for a map that already carries the id the request was given. The map lands in the drive and folder asked for, under the first free name, and is published at once under the map_id the reply announced. A premium layout, theme or scene in it is left off where your plan does not include it (the result counts them, gated), and a premium template fails premium_template.
• Nothing is ever replaced — no agent request, and from miMind 26.11.6 none of your own renames, moves, copies or recoveries, writes over a file or folder that is there. A rename, a move, a folder rename or a copy given a name fails name_taken when the name is taken, in any letter case, or when only its letter case would change; a new map, a copy without a name and a recovered map take the first free “<name> (2)”. While a device is still reading a cloud drive’s list, it waits rather than guess.
• No Undo for file changes — a new map, a rename, a move, a copy, a folder or a recovery is not a step of a map’s undo history: miMind names each change an agent made in a notice. Set it back as you would your own change, or ask the agent; a map in the trash comes back with recover_map, or in miMind on the device that trashed it.
• Copies get their own ids — duplicate_map, and from miMind 26.11.6 your own Copy, copy to another drive and Save As to a new place, give the copy a map_id of its own (an encrypted map keeps its id, and so, for now, does each map inside a folder you copy); a rename or a move keeps it, so agents still find the map.
• add_map_link is applied as the edit tools are, when the map is open, as one change you can undo; propose_trash_map waits for your answer in the map’s Agent Requests, like the other requests for your approval.
• Restoring a version — propose_restore_version is never applied on its own: it waits for your answer in the map’s Agent Requests, and you approve it with the map open in miMind 26.11.6 or later. miMind then first saves the map as it is now as a version, Before restoring the version from …, even when you have not changed it (up-to-date apps normally keep that version for 30 days, for your last five restores, within Version History’s storage budget), and then restores: the version’s nodes replace the map’s, as one step you can undo, and its look (canvas colour, wash, theme, scene, line flow, glow, grid) replaces the map’s, which Undo does not bring back — the kept version has it. From the next miMind update, the same Undo brings the look back too, in one step with the nodes. It is refused on a map you share with others and where the device records no versions (nothing changes), and nothing is restored if keeping the current map fails. If the map is open on another of your devices, close it there first: its next save would bring back what it shows.
• edit_table — applied as the edit tools are, by miMind 26.11.6 or later only, when the map is open, as one change you can undo, all of a request or none of it; it fails, changing nothing, if the table changed since the copy it was checked against (see Tables). propose_table_edit waits for your answer in the map’s Agent Requests, like the other requests for your approval. export_map_file and request_map_copies are file requests: a device that has the map or the drive does them, and neither changes a map (see Exports).
• add_to_notes, add_drawing, reorder_content, set_scene and set_title_list — applied as the edit tools are, by the next miMind update only, when the map is open, as one change you can undo, all of a request or none of it; earlier versions are never handed them, so they wait until they lapse. A drawing is checked again and turned into a picture on a background task before it is applied (see Agent drawings); an open notes drawer on that node first keeps what you typed and then shows the new items, and the full-screen notes editor holds the request until you close it.
• Changes waiting for a closed map — from the next miMind update, once we switch it on, when an agent’s change waits for a map you do not have open, the desktop and mobile apps with live delivery mark the map’s card in your list and say once a session An AI agent sent changes for "<map>". Open it to see them., with Open (with review on: An AI agent asks to change "<map>". Open it to review the request.). Opening the map applies them as usual; the mark itself applies, downloads and changes nothing. Before it marks a map, the app asks our server, at least a minute after it first saw the change, whether the request still waits and is not being applied by another device. Another device may still apply it first (then the map simply shows the change, with no banner); a mark stays until you open the map on this device or restart the app; a request queued while the app was closed may be marked too; at most 3 notices wait at once. The web app and the Windows Store app show no marks.
• Agent Activity — from the next miMind update, once we switch it on, the MCP Server dialog lists what agents asked for, newest first, 25 at a time (Load more): the map or file, what was asked (added topics, a drawing, a moved file…), when, and how it stands — waiting, being applied, waiting for your approval, applied, read (a message), undone, rejected, lapsed, failed or withdrawn. Open opens a map that is on this device; Undo takes back a file change this device made. It reads the requests our server already keeps and never shows what was asked in detail.
• Undo for file changes — from the next miMind update, on the device that made it, a file change an agent asked for can be undone: Undo on the notice of one change (Undo all, newest first, for up to five) and on its row in Agent Activity. A rename or a move goes back, a copy, a recovered map or a map an agent created goes to the app’s trash (only while it is unchanged since: The copy was changed since., for a recovered or created map The map was changed since.), and a folder an agent created is removed while it is empty, on This Device only. Nothing is ever written over a file: A file named "<name>" is there now. refuses it, a move never brings back a folder you deleted, and a map open here waits (Close "<map>" first.). Folder renames and approved trashes are not undone here. Once switched on, get_command_status tells the agent undone_by_user for a rename, a move, a copy, a new folder or a recovery; for a map an agent created it does not, so the agent’s list still shows it as created, and the map leaves list_maps when its copy is removed. The Windows Store app cannot tell whether a copy changed, so it offers no Undo for copies, recovered or created maps.
• Lapses — a request not applied within 30 days (set_background: 7) expires and stops counting. At most 20 can wait at once; past that a write is refused with Too many pending commands. and what each waiting request needs. Requests for your approval lapse after 14 days and messages after 30, and they count apart: at most 20 requests for your approval (10 for one map, Too many proposals are waiting for the user's review) and 20 unread messages (Too many unread messages are waiting for the user). cancel_command withdraws one. File requests lapse after 7 days and build_map after 30, and count among the 20.
• Reads (list_maps, read_map, search_maps, get_node, get_map_info, read_tasks) show the copy published at the last save, so a new map becomes readable once miMind has built and published it, and added, changed, moved or copied nodes, new content, links and formatting once the map is saved (an applied request publishes the map too). list_files reads where each map’s file is, as last published. get_node_content, get_map_links, get_map_thumbnail and the exports read the same copy.