SchemAgentic

MCP server

Everything else in these docs is AI working inside SchemAgentic. This is the other direction: an AI agent somewhere else — Claude Code in your terminal, Cursor or VS Code, Claude Desktop, claude.ai or ChatGPT — reading and adding to your maps, as one tool among its own.

• What it is
• Setting it up
• Connecting
• Clients
• Signing in
• The sixty-two tools
• Search and fetch
• Map view and prompts
• How writes work
• App versions
• Protocol
• What a token or app can reach

What it is

MCP — the Model Context Protocol — is how an AI client is given tools. Point one at this server and it can list your maps, read them, search them, read one node or a map's tasks in full, export one as Markdown, OPML, CSV or JSON, create one, add nodes to one, rename, restyle and move the nodes of one, and change the scene behind one, then follow up on what it asked for, in the middle of whatever else it is doing: "check my Roadmap map and add anything from this week's notes that is missing."

Setting it up

You need:

• A Business or Pro subscription, signed in to your SchemAgentic account with a verified email.
• The SchemAgentic app on your computer or phone. The web app has no MCP Server dialog yet, and only an app publishes your maps and carries out what an agent asks for.

1. Open the menu, then Settings, AI Settings and MCP Server… (from an open map or from the file list).
2. Turn on Sync my maps to the MCP server. Nothing is readable until you do — the server reads a copy of the maps the app has published, never your files.
3. Press Generate New Token and copy the token. It is shown once: the server keeps only a hash of it. From the next SchemAgentic update you choose first: Can read and change maps, or Can only read maps for a token that only reads (see read only). You can have up to 5 tokens at a time; revoke one in the same dialog to remove it.
4. Copy the Server URL from the dialog and set up your client with both (recipes below).

What gets published

Publishing is for the whole account, not per map: while the switch is on, each map you save is published — from the next SchemAgentic update, each map you open as well. That includes a map someone shared with you, which goes to your own copy (agents can read it, never change it). For each map the copy holds:

• Node titles and notes, each shortened to 160 characters, for up to 800 nodes, the whole outline up to 256 KB — one line per node, in the order the map holds them. Never attachments, images, agents, services, credentials or connections.
• From the next SchemAgentic update, a full copy beside it, for 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, 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, 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, nor an agent, service, credential or connection. A map an older app published has the outline alone, and the tools say so.
• Tables, lists and a picture, once switched on: from the next SchemAgentic update, 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 SchemAgentic 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 the next SchemAgentic update: the updated app gives each node a hidden id the first time it saves the map with the switch 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 older app drops them when it saves the map.
• Where each map's file is, once file places are switched on: from the next SchemAgentic update, the drive, the folder and the file name of each map the app publishes with the switch on, for list_files and the file tools; never the full path on your device (see what a token or app can reach).
• Maps shared with you, from the next SchemAgentic update: 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).
• Agents read this copy, so they see a map as you last saved it (or, from the next update, last opened it).

From the next SchemAgentic update:

• Encrypted maps are never published, and 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 the switch on, and once, with the switch 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 older app published from elsewhere (such as a cloud-storage folder), keeps its copy until an updated desktop or mobile app opens it with the switch on, or you turn the switch 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. Older apps publish an encrypted map's outline like any other, so update SchemAgentic on every device that syncs.
• Deleting a map in the updated 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 the switch 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 the app, or one an older app published that the update has not opened since. Turning the switch off asks whether to remove every map the account published (Remove or Keep). The switch 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. The app makes these removals only while you are signed in on a plan that includes MCP. Older apps never remove a copy.
• A map can be kept out on its own: in the open map's menu, Settings, turn off Visible to MCP Agents (shown while the switch is on, for a map that is not encrypted). Its copy is removed, the server will not store it again, and agents' requests for it are refused. From the next SchemAgentic update, the owner of a map shared with others finds Visible to MCP Agents in the map's menu and in its Share panel, with Sync my maps to the MCP server on or off, and turning it off there hides the map from every member's agents too (see Maps shared with you).
• The switch is kept per account: another account signed in on the same device starts with it off. The MCP Server dialog shows when your maps last synced, or why the last sync failed.

Maps shared with you

From the next SchemAgentic update, 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 the switch 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. A map's agents, services, approvals and ports are never read.

• 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 SchemAgentic. 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 my maps to the MCP server 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 the switch on, an hour later or after their app restarts (with an older app, 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

SchemAgentic's Version History keeps saved versions of a map. From the next SchemAgentic update 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 the next SchemAgentic update while the map was published with the switch 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 the switch 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 SchemAgentic update, Undo brings the look back too). Refused for a map you share with others (restore it yourself from Version History), for maps others share with you, and for a map whose agents or services can run (turn them off first; see Restoring a version).

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

From the next SchemAgentic update, once our server takes it, the full copy of each map your app publishes with the switch 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. A map's agents' run records, services, approvals and ports are never part of it.

• 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 SchemAgentic 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 older app, 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 the next SchemAgentic update, 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 SchemAgentic 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 older app 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, and the agents standing on its nodes with their status, as drawn.
• Where it goes. It is kept inside the map's copy on our server and deleted with it (see what a token or app can reach).

Word search

From the next SchemAgentic 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 the switch 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 is 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 SchemAgentic 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 SchemAgentic update checks the drawing against the same rules, draws it in the background with the app'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. Older SchemAgentic apps, 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 SchemAgentic 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.

Connecting

Every client needs the same two things: the server URL and your token, sent as a bearer header.

https://us-central1-schemagentic.cloudfunctions.net/mcp
Authorization: Bearer mmcp_YOUR_TOKEN

With Claude Code, one command does it:

claude mcp add --transport http schemagentic \
  https://us-central1-schemagentic.cloudfunctions.net/mcp \
  --header "Authorization: Bearer mmcp_YOUR_TOKEN"

Every other client is under Clients. Then ask for what you want:

• "What is in my Product Roadmap map?"
• "Search my maps for anything about onboarding."
• "Make a map from this README's structure."
• "Add the open questions from this thread under 'Risks' in my Launch map."
• "In my Launch map, make 'Risks' bold with a red border and move it under 'Engineering'."
• "Put the Misty Peaks scene behind my Launch map."
• "Has my Launch Plan map been built yet?"

Clients

The server speaks MCP's Streamable HTTP transport and takes a token in a request header. Any client that can send a header can use it. Clients that sign in instead (claude.ai, Claude Desktop's connectors, ChatGPT, Claude Code) need no token: see Signing in.

Claude Code

The command above adds the server for the project you run it in; add --scope user to have it in every project. To share it with a project instead, put it in the project's .mcp.json, and keep the token out of the file with an environment variable:

{
  "mcpServers": {
    "schemagentic": {
      "type": "http",
      "url": "https://us-central1-schemagentic.cloudfunctions.net/mcp",
      "headers": { "Authorization": "Bearer ${SCHEMAGENTIC_MCP_TOKEN}" }
    }
  }
}

Claude Desktop

Claude Desktop's own Connectors screen signs in instead of sending a token (see Signing in). With a token, connect through the mcp-remote bridge (it needs Node.js 18 or later) in claude_desktop_config.json. The header goes in an environment variable: Claude Desktop on Windows does not pass spaces inside args through.

{
  "mcpServers": {
    "schemagentic": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://us-central1-schemagentic.cloudfunctions.net/mcp",
        "--header", "Authorization:${AUTH_HEADER}"
      ],
      "env": { "AUTH_HEADER": "Bearer mmcp_YOUR_TOKEN" }
    }
  }
}

Cursor

In .cursor/mcp.json in a project, or ~/.cursor/mcp.json for every project. Cursor reads ${env:NAME} in a header from your environment:

{
  "mcpServers": {
    "schemagentic": {
      "url": "https://us-central1-schemagentic.cloudfunctions.net/mcp",
      "headers": { "Authorization": "Bearer ${env:SCHEMAGENTIC_MCP_TOKEN}" }
    }
  }
}

VS Code

In .vscode/mcp.json (or the mcp.json of your user profile). VS Code asks for the token the first time the server starts and keeps it out of the file:

{
  "inputs": [
    { "type": "promptString", "id": "schemagentic-token", "description": "SchemAgentic MCP token", "password": true }
  ],
  "servers": {
    "schemagentic": {
      "type": "http",
      "url": "https://us-central1-schemagentic.cloudfunctions.net/mcp",
      "headers": { "Authorization": "Bearer ${input:schemagentic-token}" }
    }
  }
}

Any other client

Add a Streamable HTTP server with the URL and the Authorization: Bearer mmcp_… header. The server is stateless: POST a JSON-RPC 2.0 message and the answer comes back as plain JSON, with no event stream and no session. To try it by hand:

curl -X POST https://us-central1-schemagentic.cloudfunctions.net/mcp \
  -H "Authorization: Bearer mmcp_YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2025-06-18" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_maps","arguments":{}}}'

Signing in: claude.ai, Claude Desktop, ChatGPT and Claude Code

Connectors that sign in need no token. Give them the address https://schemagentic.web.app/mcp (not schemagentic.app or .ai: they serve the same site, but signing in belongs to schemagentic.web.app). When you connect, your browser opens SchemAgentic's own sign-in page on schemagentic.web.app: sign in with your SchemAgentic account, check which app is asking, and press Allow. The app then keeps its access without you copying anything, until you disconnect it.

claude.ai and Claude Desktop. Open Settings → Connectors, choose Add custom connector, name it SchemAgentic, paste https://schemagentic.web.app/mcp as its URL, add it and press Connect; sign in on the page that opens and press Allow. On a Team or Enterprise plan an Owner adds it for the organisation first. Claude Desktop and Claude's mobile apps use the connectors of your claude.ai account.

ChatGPT. Turn on Developer mode in ChatGPT's settings (under Apps & Connectors, then Advanced settings; OpenAI moves it from time to time, and your plan or workspace admin decides whether you have it), create a connector with the URL https://schemagentic.web.app/mcp and OAuth as its authentication, then sign in and press Allow. A ChatGPT connection also gets search and fetch, for ChatGPT's search and deep research.

Claude Code. Add the server without a header, then run /mcp inside Claude Code, pick schemagentic and choose to authenticate. Your browser opens the sign-in page, which names the app as an app on this computer, and Claude Code keeps the sign-in:

claude mcp add --transport http schemagentic https://schemagentic.web.app/mcp

VS Code, Cursor and the mcp-remote bridge

Once we add them (after signing in is switched on; until then the sign-in page says This app is not one SchemAgentic can connect to. and they keep using a token), these three sign in from the app on your computer, with no token. The sign-in page names the app and says an app on this computer, and so do Manage Account and get_sync_status: any program on your computer could ask under these names, so allow only a sign-in you just started.

VS Code (the desktop app): in .vscode/mcp.json or your user profile's mcp.json, with no header. VS Code opens the sign-in page when it starts the server.

{
  "servers": {
    "schemagentic": { "type": "http", "url": "https://schemagentic.web.app/mcp" }
  }
}

Only VS Code on your desktop signs in: a VS Code Remote window (SSH, a container, WSL) and vscode.dev keep the token recipe above, and VS Code Insiders is not one SchemAgentic knows yet.

Claude Desktop through mcp-remote: the bridge signs in for Claude Desktop with SchemAgentic's own client document. In claude_desktop_config.json (it needs Node.js 18 or later, as the token recipe does):

{
  "mcpServers": {
    "schemagentic": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://schemagentic.web.app/mcp", "3334",
        "--client-metadata-url", "https://schemagentic.web.app/oauth/clients/mcp-remote.json"
      ]
    }
  }
}

Keep the port 3334: the sign-in comes back to it on your computer, as the client document says.

Cursor (the desktop app): in .cursor/mcp.json or ~/.cursor/mcp.json:

{
  "mcpServers": {
    "schemagentic": {
      "url": "https://schemagentic.web.app/mcp",
      "auth": { "CLIENT_ID": "https://schemagentic.web.app/oauth/clients/cursor.json" }
    }
  }
}

Cursor on the web and its background agents keep the token recipe above.

• Read, or read and change. The sign-in page always lets the app read your synced maps. When the app asks to change them too, it shows Also queue changes to your maps (SchemAgentic applies them, and you can undo each one), ticked: untick it and the app can only read (see read only).
• Only apps SchemAgentic knows. For now claude.ai (with Claude Desktop and the mobile apps), Claude Code and ChatGPT can connect. The page names the app and its web address, or an app on this computer for Claude Code. Once we add them, VS Code, Cursor and the mcp-remote bridge on your computer can connect too (see above), each named with an app on this computer.
• A subscription. Connecting needs Business or Pro, as a token does; the page says so when it is missing.
• Always on schemagentic.web.app. When an app connects, SchemAgentic always sends you to schemagentic.web.app to sign in, and that page works on no other address: check the address bar before you sign in. The connecting app never sees your password.
• How long it lasts. A connected app works until you disconnect it, renewing its access by itself: its access token lasts 60 minutes. A connection not used for 30 days ends, and every connection ends 180 days after you allowed it: connect again then. You can have up to 20 connected apps. Changing your password, or signing out of all devices, disconnects every app within an hour.
• Ending it. Manage Account lists every connected app and every token, when each was connected and last used, and what they did recently, and disconnects or revokes them, with or without a subscription. From the next SchemAgentic update the MCP Server dialog lists them too, under Connected Apps, with Disconnect…. A disconnected app stops at once and is deleted from our server.
• Tokens and requests on the web. Once we switch it on, Manage Account can also make a token: it asks you to confirm that it is you first (with your password, or in your sign-in provider's window) and shows the token once — copy it then: it is kept nowhere, and it leaves the page after 10 minutes, when you press Done or when you leave the page. Agents see the maps a desktop or mobile app with Sync my maps to the MCP server on has published; the web app does not publish maps. The page also lists what agents left waiting for you: reject a request, or mark a message as read. Approve requests in the SchemAgentic app with the map open: the device that approves applies the change. The page never approves; that is its own rule, since our server cannot tell the page from the app, and an approval sent some other way applies nothing (the request shows as being approved elsewhere for 10 minutes). The check before a token is made is the page's own too: whoever can use your signed-in browser can make a token, so sign out of SchemAgentic on a computer you share.

The sixty-two tools

Every tool carries a title and hints a client can show (readOnlyHint on the reads; the direct writes only queue and never delete or replace, and the four that ask for your approval change nothing until you give it; destructiveHint is true on update_nodes, move_nodes, set_map_style, connect_nodes, format_nodes, refine_map_style, propose_delete, propose_replace, revert_command, propose_trash_map, rename_map, move_map, rename_folder, propose_restore_version and propose_table_edit, which change or remove what a map already has, or where its file is (the requests for your approval only once you approve them), so some clients ask you before they call them). The tools from list_maps to cancel_command do not refuse arguments they do not expect, and bring a number out of range into range (except add_nodes' index, which must be 0 or more, and parent_eid, which must be an eN label); the edit tools refuse a node, change or move with a field they do not know, and bring only an index past the end into range. The reads from get_node on, and the new arguments of list_maps, read_map and search_maps, read an unknown format, scope or kind as its default and bring a number into range.

Ten work with files and folders, from the next SchemAgentic update: 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 or text, 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. 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.

Then seven, from the next SchemAgentic update, 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 the next SchemAgentic update, 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 SchemAgentic app to save an export as a file on your device, and to publish the copies agents read of maps that have none yet. 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.

The last seven, from the next SchemAgentic 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. A token made with Can only read maps (from the next SchemAgentic update), or an app connected with changes not allowed, lists only the read 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). To let it change maps, make a new token, or connect the app again and allow changes.

list_maps read

The published maps, most recently updated first, up to 100 a page. When there are more, the reply ends with (More maps: call list_maps with cursor "…".). Each map is one line: - map_id: <id> | "<title>" | N nodes | updated <ISO time>. With nothing published yet, the reply says to turn on Sync my maps to the MCP server.

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: … | SchemAgentic 26.11.3 (Mac) | full copy | 1500 nodes in the map. A copy an older app published says older app and text outline only, and cut when it misses nodes; a map published before the server kept this ends | publisher unknown.

read_map read

One map: a first line Map "<title>" (map_id: <id>, N nodes), then the outline. Each node is one line, indented two spaces per level, in this form:

e0 Launch Plan
  e1 Marketing  — owner: Dana, due in May
    e2 Email campaign
  e3 Engineering

• eN is the node's position in this copy, counted depth-first from e0, the first central topic. It is not an id: it changes when the map changes. To name a node exactly, even one whose title others share, an agent passes the label with this read's revision to insert_nodes, update_nodes, move_nodes or add_nodes (parent_eid), which refuse a revision once the map has been saved again (see Editing nodes); otherwise it names a node by its title.
• Ids last; labels do not. From the next SchemAgentic update 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 the switch on, and a copied node gets a new one; an older app 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 the next SchemAgentic update the edit tools and add_content take ids too, as id:n3k9x0ab wherever they take a node (see Editing nodes), 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.
• After " — " come the node's notes. Titles and notes longer than 160 characters end in …, and a copy cut short (past 800 nodes, or past 256 KB of text) ends with the line … (map truncated for length).
• A long outline comes in pages of whole lines, each ending with … (lines A-B of N; call read_map with offset=B to continue). The pages joined with a line break are the outline exactly.
• The structured result also carries revision, a fingerprint of the copy this read shows, the same on every page. The text does not show it, so a client without structured output (see Protocol) passes labels without one (they are then read in the current copy, with the warning revision_assumed) or names nodes by title.

Formats, branches and depth. Without these three, 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. 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 it has none (the head line says full copy or text outline only), in pages of whole nodes: offset is the node to start at, and a page that does not reach the end finishes with … (nodes A-B of N; call read_map with format=F, offset=B to continue).
• json gives one JSON object per line, each node as get_node describes it, and on the last page a {"link": …} line for each cross-link inside the selection; markdown a heading and a bulleted list, with notes, check boxes (- [ ], - [x]) and links one level deeper; opml a whole OPML 2.0 document on every page; csv one row per node, with the header on the first page; plain the indented titles and notes without labels. The structured result of an export carries it in content, with mime_type and filename, so a client can save it.

{ "map_id": "id_1730450000_9f2c", "format": "json", "node": "e1", "depth": 1,
  "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418" }

Map "Launch Plan" (map_id: id_1730450000_9f2c, 4 nodes) — json, full copy, branch e1 "Marketing", depth ≤ 1

{"eid":"e1","id":"n0k2m9qa","parent":"e0","depth":1,"title":"Marketing","note":"owner: Dana, due in May","children":1,"style":{"fill":"#336699","bold":true}}
{"eid":"e2","id":"n7c1x4rb","parent":"e1","depth":2,"title":"Email campaign","children":0,"content":[{"kind":"check","text":"List cleaned","checked":true},{"kind":"link","text":"Brief","url":"https://example.com/brief"}]}

{ "map_id": "id_1730450000_9f2c", "format": "markdown" }

Map "Launch Plan" (map_id: id_1730450000_9f2c, 4 nodes) — markdown, full copy

# Launch Plan

- Launch Plan
  - Marketing
    - owner: Dana, due in May
    - Email campaign
      - [x] List cleaned
      - [Brief](https://example.com/brief)
  - Engineering

search_maps read

Case-insensitive search of the published maps' titles and lines (node titles and notes). Each matching map is listed with its matching lines. It searches up to 200 maps a call, most recently updated first, and stops at a map once the reply is about 45,000 characters long; when older maps remain, the reply ends with a cursor that searches them. A search counts as 5 calls towards the rate limit.

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; a matching line reads e12 Budget — …about 160 characters around the hit…, and the structured result adds each hit's label, id and where it was found. Maps an older app published are searched as before, and the reply ends by saying how many there were.

create_map write

Queues a new map. title becomes the central topic, and the outline's top-level lines become its branches:

{ "title": "Launch Plan",
  "outline": "Marketing\n  Email campaign\n  Landing page\nEngineering\n  Release checklist\nSupport" }

• Indent children under their parent with spaces or tabs, any consistent width. The server tidies the outline before it queues it: bullets, list numbering and read_map's eN labels come off, and an outline whose only top-level line repeats the title is built with that line as the central topic. The reply says what was tidied.
• Text after " — " on a line is that node's note, never part of its title. The next SchemAgentic update writes it into the node; older apps leave it out. The reply counts the notes, and warns notes_not_written when none of your recent devices can write them.
• There are no layout arguments: a new map gets the default layout.
• background puts one of the scenes behind the new map; an app from before scene backgrounds builds it without one.
• theme gives the new map one of the theme names below: its colours, node shapes and lines, as the theme strip in the style sheet does. Case, spaces, underscores and hyphens are forgiven, and an unknown name is refused with the list. The next SchemAgentic update applies it; older apps build the default look, and the reply warns theme_unsupported when none of your recent devices can apply it.
• The map is built the next time SchemAgentic starts, or you sign in, on a device with the switch on — by one device only (see How writes work).
• Its map_id: today's apps give the new map its id when they build it, so the reply says the id is not known yet, and get_command_status reports it once the map appears in list_maps, which happens after you open and save it. The next SchemAgentic update builds the map under an id the server chose (a new one, should the device that picks the request up stop before building it) and publishes it at once; when every device that synced in the last 30 days has that update, the reply says Its map_id will be <id>.

The 52 theme names, the ones the AI assistant uses, which never change: 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.

{ "title": "Onboarding",
  "outline": "Accounts  — before day one\n  Laptop\n  Email\nFirst week\n  Buddy  — someone outside the team",
  "theme": "harbor" }

add_nodes write

Queues new nodes for an existing map, added the next time that map is open (at once if it is open now, from the next SchemAgentic update), as one change you can undo. Notes after " — " are written as each new node's note by the next SchemAgentic update, as for create_map.

• parent_title must match a node's title in the copy read_map shows (case and spacing do not matter; an eN label in front is understood). Otherwise the request is refused: No node titled "…" in "…" as last saved, with similar titles when there are some. If you just added that node, save the map and ask again.
• Leave parent_title out to add under the first central topic. When several nodes share the title, the first one (depth-first) is used, and the reply says so.
• Two exceptions: in a map whose copy is cut short (past 800 nodes or 256 KB), a title that is not in the copy is queued anyway (the node may be past the cut), with a note; and a title cut at 160 characters in the copy cannot be matched, so name the node by its full title or pick another.
• Older apps put the nodes under the central topic when the map no longer has a node with that title (renamed or removed since the copy was published). The next SchemAgentic update adds nothing then and reports the request failed.
• With parent_eid or index the request is an exact edit, like insert_nodes: parent_eid names exactly that node (a parent_title given too must name the same one), and the first top-level line goes at index among its children. Only the next SchemAgentic update applies it (the reply warns device_update_needed when none of your recent devices can), and a node it cannot find when the map opens fails the request with target_changed. Without them, add_nodes works as before.

set_background write

Changes the scene behind a map you already have: one of the scene ids, or none to take the scene away. Case, spaces and underscores are forgiven (Misty Peaks means misty-peaks), and an unknown id is refused with the list. The change is made the next time that map is open (at once if it is open now, from the next SchemAgentic update), as one step you can undo — the same step the map chat takes when you ask it for a background. A newer request for the same map replaces one still waiting, and a request not applied within 7 days lapses; an app from before scene backgrounds never applies one. Putting a scene on needs a subscription in the app, as it does everywhere; taking one away never does.

The scenes

Scenes are gentle by design — sparse, slow and quiet in the middle, low in contrast on a dark theme and a daylight picture on a light one (northern-lights alone is a vivid aurora on a dark theme) — so the map stays readable, and their colours follow the map's theme. Most move slowly, many in depth; the ones marked still do not. These are the 38 scenes SchemAgentic 26.9.18 has, grouped as its style sheet groups them:

The tools' own list is longer: it also names 26 scenes of a newer scene catalogue (forests, the ocean, wind and silk waves and a few more), because the server never knows which app will open a map. This version of SchemAgentic does not have them: a new map is built without such a background, and a set_background naming one waits for an app that has it and lapses after 7 days. When the server can tell that none of your devices has the scene, the reply says so (scene_needs_update).

Designing a new scene with AI is done in the app, not over MCP — see AI.

get_command_status read

What became of a request a write tool queued: its status, when it was queued, picked up by a device and finished, the app's message, and for a pending one Waiting for: … (the app starting, you opening the map, an app new enough for its scene or edit). For a map create_map built, it gives the new map's id once it is known — probably map_id … when it is matched by title (the only map of that title published after the build).

From the next SchemAgentic update the app also reports a result: its code (created, applied, already_applied, or a failure code) and what it counted — nodes_added, nodes_requested and nodes_skipped for new nodes; for an edit, ops_requested, ops_applied (0 when everything already was as asked), failed_op (which change stopped a failed one) and bound (exact when the map had not changed since the read, anchors when its nodes were found by title and place); notes_written and theme_applied for notes and a theme. An edit's status also gives revision (the copy it was checked against) and ops (how many changes it holds).

When the next SchemAgentic update 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

The requests queued for your app, newest first, one line each: - <command id> | <type> | "<title>" | <status> | queued <time> | <what it waits for, or how it ended>, where the type is the tool that queued it. A long list ends with a cursor for the next page.

cancel_command write

Withdraws a request your app has not applied yet; it changes nothing but the queue. A finished request is left as it is (already done; nothing to cancel). If a device has already picked the request up — a create_map being built — it may still be applied, and the reply says so (command_leased).

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 or shape, 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 (at once if it is open now, from the next SchemAgentic update) 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.

Only the next SchemAgentic update applies them. Older apps never see these requests, which wait for an updated app until they lapse (30 days after they were queued); the reply warns device_update_needed when none of your recent devices can apply them.

• Naming a node. An eN label from read_map names exactly that node, even when others share its title; pass the read's revision with it. A title works when only one node in the map has it (case and spacing ignored): when several have it the request is refused with their labels, and when none has it, with up to five similar titles. A title cut at 160 characters in the copy, or a node past the end of a copy cut short, cannot be named that way: pick a node the copy shows, by its label, or by its id.
• Naming a node by id (from the next SchemAgentic update). 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, the app 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. Given with labels, a revision is checked against the copy on the server now: once the map has been saved again the request is refused (has changed since that read) and nothing is queued, so read the map again for fresh labels. Labels without a revision are read in the current copy, with the warning revision_assumed naming the node each one was read as.
• When the map opens, the app finds each node: 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.
• Formatting. Colours are #RRGGBB (#RGB, and either without the #, are accepted). Shapes: rectangle, rounded, rounded25, capsule, ellipse, diamond, cloud, hexagon. Setting a colour or a shape changes only that: the node keeps its frame, shadow and fill as they were. There are no dates here: the SchemAgentic server offers no layouts, so the edit tools take no date.
• Premium layouts. On a device whose plan has no premium layouts, a request that adds, renames, bolds 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, and no upgrade prompt opens.

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 and a shape. Nodes nest by level. Applied the next time the map is open (at once if it is open now, from the next SchemAgentic update), as one change you can undo. Nothing is deleted or replaced.

{ "map_id": "id_1730450000_9f2c", "parent": "e3", "index": 0,
  "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
  "nodes": [
    { "title": "Load test", "bold": true, "fill_color": "#FFE08A" },
    { "title": "Staging run", "level": 1, "note": "Two days before launch" }
  ] }

The reply: Queued (command <id>). 2 nodes will be added under "Engineering" (e3) at position 0 in "Launch Plan" the next time the user opens that map in SchemAgentic, as one change the user can undo.

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), and a shape. Nothing is deleted, and no note or content changes. Applied the next time the map is open (at once if it is open now, from the next SchemAgentic update), 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. The reply lists up to ten changes, then (and … more):

Queued (command <id>). 2 changes to "Launch Plan" will be applied the next time the user opens that map in SchemAgentic, as one change the user can undo:
- e1 "Marketing": renamed to "Marketing and PR"; bold; fill #FFCC00 (whole branch)
- e2 "Email campaign": shape capsule

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). Moves run in the order given, and every label names the node as read_map showed it. Central topics stay where they are in this version, and a node cannot move into its own branch, even one an earlier move of the same call made: both are refused when the request is made. Nothing is deleted. Applied the next time the map is open (at once if it is open now, from the next SchemAgentic update), as one change you can undo.

Queued (command <id>). 1 move in "Launch Plan" will be applied the next time the user opens that map in SchemAgentic, as one change the user can undo:
- e2 "Email campaign" -> under e3 "Engineering" after its last child

Reading in depth: the full copy and ids

The tools below, like read_map's formats, read the full copy the next SchemAgentic update publishes beside the outline: whole titles and notes, styles, 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 older app 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, 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

One node in full: its path from the central topic, its whole note, its style, 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. A line with nothing to say is left out. At most 200 children are listed, then … and N more: read_map with node=e12, depth=1. On a copy with the outline alone only the title, the note as the outline cut it, the path and the children are known, and the reply says so.

Node e1 "Marketing" in "Launch Plan" (map_id: id_1730450000_9f2c, revision 9B2F0C61D4E8A7735A1C0E96F3B2D418)
Id: n0k2m9qa
Path: e0 Launch Plan › e1 Marketing
Note: owner: Dana, due in May
Style: fill #336699, bold
Children (1):
- e2 Email campaign
Cross-links (1):
- to e3 Engineering "needs the landing page"

The structured result has map_id, title, revision, source and node: the node as the json format gives it, plus its path, child_list, children_total and cross-links (links, each to or from another node, with its label).

get_map_info read

What a map is made of, without reading all of it, in about ten lines: how many nodes the copy holds and the map has in all, its central topics (up to 50) and how deep it goes, how many nodes have notes or are collapsed, how many tasks are open and done, how many cross-links and content items of each kind it has, its theme, scene and background colour, who published it, and its revision. On a copy with the outline alone, what only the full copy can tell is left out, and the reply says so.

read_tasks read

The check-box tasks of your maps, or of one map: open ones by default, map by map, each with its node's label, id and path. It can list dated nodes too, for a map whose nodes have dates. Without map_id it looks through up to 200 maps a call, newest first, and reads in full only those whose full copy holds 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 older app published have no tasks the tool can see: the reply counts them and says that saving them in an updated app publishes them. A read_tasks call counts as 5 towards the rate limit.

Open tasks — 3 in 1 map (12 maps scanned):

"Launch Plan" (map_id: id_1730450000_9f2c)
- [ ] Book the venue — Launch Plan › Marketing › Event (e5)

list_catalog read

The names the other tools take, so an agent can choose without guessing: the themes and which of them come with the app at no extra cost, the scenes the tools name (those of the scenes and the newer ones), each with its name, group and whether it is still, and the shapes with the other names each is read by, the line styles and animations connect_nodes takes, and the fonts, node shapes and numbering format_nodes takes. SchemAgentic takes no layouts, so layouts lists none. It reads no map.

The structured result has the kinds asked for: themes[], layouts[], scenes[] and shapes[] (id, aliases); arranged_themes[] and washes[]; lines and animations; and fonts (families, and size with its min and max), node_shapes[] (id, aliases) and numbering (types, none among them; colorings; aligns; size); and templates (revision 0 and no categories, with the text SchemAgentic has no template catalogue yet.). my_scenes[] (id, name — your own words, which the tool tells the agent to treat as data —, created, source) and scene_format (text: the keys, layers, colour roles, motion and limits SchemAgentic'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

Who this connection is signed in as and how your SchemAgentic apps sync: the email the token was made with, its label and how it starts, how many maps are published and hidden from agents and when the last one was published, the devices that picked up requests in the last 30 days (version, platform and what each can apply), and how many requests are waiting. No device name or id, and nothing about your plan. It takes no arguments.

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

While file requests are switched on, a device of the next SchemAgentic update also lists file and folder requests among what it can do, and while map links or the trash are, map links and trash requests.

Once switched on, a device of the next SchemAgentic 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 SchemAgentic 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 SchemAgentic (at once if it is open now, from the next SchemAgentic update), as one change you can undo. It needs the next SchemAgentic update; 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 SchemAgentic 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 plan that includes this server includes them all. Content and notes may be added in a branch arranged by a premium layout.

{ "map_id": "id_1730450000_9f2c",
  "revision": "9B2F0C61D4E8A7735A1C0E96F3B2D418",
  "additions": [
    { "node": "e3", "type": "table", "title": "Costs", "headers": ["Item", "Q1", "Q2"],
      "rows": [["Venue", 1200, 1350], ["Food", 340.5, 410]] },
    { "node": "e3", "type": "image", "url": "https://example.com/venue.jpg" },
    { "node": "e3", "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 "Launch Plan" will be made the next time the user opens that map in SchemAgentic, 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 theme, for the whole map or one branch, including the arranged layouts' own themes; and the canvas (a colour, a gradient wash, or a scene with its dials). SchemAgentic takes no layouts here, so this tool changes no layout. Nothing is deleted, and no node's text, note or content changes. Applied the next time that map is open in SchemAgentic (at once if it is open now, from the next SchemAgentic update), as one change you can undo: Undo puts the themes and canvas back exactly as they were. It needs the next SchemAgentic update; older versions leave it waiting until it lapses.

On a device whose plan does not include a theme or a scene, the request fails whole with 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. The structured result lists changes[] (what, node, node_title, summary).

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) and its own theme. Nothing is deleted or replaced, and the trees the map has stay where they are; new topics are placed clear of every tree. Applied the next time that map is open in SchemAgentic (at once if it is open now, from the next SchemAgentic update), 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 the next SchemAgentic update.

{ "map_id": "id_1730450000_9f2c",
  "topics": [
    { "title": "Hiring plan", "theme": "sunset",
      "nodes": [ { "title": "Roles" },
                 { "title": "Engineer", "level": 1,
                   "content": [ { "type": "checkbox", "text": "Post the job" } ] } ] }
  ] }

The reply starts Queued (command <id>). The structured result lists topics[] (id, title, nodes); 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 the 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 SchemAgentic (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 the next SchemAgentic update; older versions leave it waiting until it lapses.

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.

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.

{ "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. The structured result lists changes[] (what link, line or lines; from and to, the 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).

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 SchemAgentic (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 the next SchemAgentic update; older versions leave it waiting until it lapses.

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.

{ "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. The structured result lists changes[] (node, node_title, scope, fields, the formatting keys given, and summary).

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 SchemAgentic (at once if it is open now; see Live delivery), as one change you can undo; focusing is not an undo step. It needs the next SchemAgentic update; 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.

{ "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. The structured result lists changes[] (what check, fold or focus; node; node_title; summary).

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 SchemAgentic (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 the next SchemAgentic update; 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.

{ "map_id": "id_1730450000_9f2c",
  "copies": [ { "node": "Q1", "parent": "Q2", "index": 0 },
              { "node": "Template", "as_central_topic": true } ] }

The reply starts Queued (command <id>). The structured result lists copies[] (id, its n1-style name in the request; node; title; parent; parent_title; nodes, how many it copies); 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 SchemAgentic (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 the next SchemAgentic update; 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.

{ "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. The structured result lists changes[] (what spacing, restyle or effects; node, empty for the map's effects; node_title; summary).

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 SchemAgentic, 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 the next SchemAgentic update; older apps never show it.

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. If a node it deletes, or one below it, runs one of your agents or services, the request says so: the agent or service pauses until the node comes back (an Undo brings it back).

{ "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 SchemAgentic:, 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. The structured result has 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 the next SchemAgentic update.

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.

{ "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 SchemAgentic: and lists the changes (- the notes of "Budget" (replaced: 34 characters)). The structured result is 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 the next SchemAgentic update 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 SchemAgentic, and one you approved through Agent Requests (only the app'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.

{ "command_id": "a7Kq2mXr9TzLpQ4vB1cD", "reason": "Those were added to the wrong map." }

The reply starts Queued (command <id>) for the user's approval in SchemAgentic: and names the nodes it would delete. The structured result has 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 SchemAgentic'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 the next SchemAgentic update.

{ "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 SchemAgentic's Agent Requests. It changes nothing and lapses unread after 30 days. The structured result has 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 SchemAgentic 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 SchemAgentic, only on that device. Unanswered, it lapses after 14 days. It needs the next SchemAgentic update; older apps 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 SchemAgentic: ask the user to stop sharing it first); for a map that agents or services run on (any of its agents or services not turned off: the user stops them in the app first; a request never stops them); 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, has an agent or service turned on, or is 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.

{ "map_id": "id_1730450000_9f2c", "reason": "Launch 2026 replaced this plan." }

The reply: Queued (command <id>) for the user's approval in SchemAgentic: 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. The structured result has 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

Your maps with where their files are — the drive, the folder and the file name, as SchemAgentic last published them — and the folders that hold them, 100 maps a page: by drive, 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 SchemAgentic published with the switch 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 SchemAgentic 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.

{ "drive": "cloud", "folder": "Plans" }

The structured result has 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 SchemAgentic app to build, like create_map but with more: several central topics with their nodes, notes and content (topics); or text in a format — an indented outline, Markdown, OPML, FreeMind, CSV or JSON — that the server turns into nodes; and where its file goes (drive, folder and file name). One device builds it with the next SchemAgentic update, 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 is 3 requests. SchemAgentic has no template catalogue yet, and takes no layouts here. create_map keeps working with every app.

Text formats

Text is turned into nodes on our server before anything is queued; SchemAgentic'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 after the title, and nodes deeper than 30 levels are placed at level 30.

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; and, as create_map does, scene_needs_update and theme_unsupported. A premium 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).

{ "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>). SchemAgentic 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. The structured result has command_id, status, title, map_id (when certain), map_id_certain, source (topics or text), 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 the next SchemAgentic update, 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.

{ "map_id": "id_1730450000_9f2c", "name": "Q3 plan (final)" }

The reply starts Queued (command <id>). SchemAgentic renames the file of "Q3 planning" to "Q3 plan (final)". The structured result has 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.

{ "map_id": "id_1730450000_9f2c", "folder": "Archive/2026" }

The structured result has 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 the next SchemAgentic update, 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 SchemAgentic). 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).

{ "map_id": "id_1730450000_9f2c", "name": "Q4 planning", "drive": "local" }

The structured result has 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 the next SchemAgentic update. 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.

{ "path": "Clients/Acme", "drive": "cloud" }

The structured result has 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 the next SchemAgentic update; 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.

{ "path": "Clients/Acme", "name": "Acme Corp", "drive": "cloud" }

The structured result has 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 SchemAgentic'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. (For now a map link card in SchemAgentic does not open a map when clicked: opening one could start its agents or services.) 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 SchemAgentic (at once if it is open now), as one change you can undo, by the next SchemAgentic update 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).

{ "map_id": "id_1730450000_9f2c", "node": "Budget", "target_map_id": "id_1730460000_4a1b" }

The structured result has 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 the next SchemAgentic update: 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 SchemAgentic are not known to the server: recover those in SchemAgentic.

{ "map_id": "id_1730450000_9f2c" }

The structured result has command_id, status, map_id, title, expires_at and warnings.

list_shared_maps read

The maps you share with other people and those others share with you, among those whose copy your SchemAgentic app has published (with the switch 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 (every cloud map of yours has a share record, so those count too), and a call is 11 requests. Read-only: sharing, invitations and roles stay in SchemAgentic.

It warns list_cut when you are in more than 1,000 share records, not_mirrored with how many shares have no copy agents can read (open each once in an up-to-date SchemAgentic with the switch on), and authors_unverified when it names who saved a map.

{ "role": "owned" }

The structured result has maps[] (map_id, title, role, owner, members, last_saved, last_saved_by, mirror_updated), not_mirrored, next_cursor and warnings.

get_map_members read

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 SchemAgentic.

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

{ "map_id": "id_1730450000_9f2c" }

The structured result has members[] (name, role, is_you, is_owner, active_now, last_seen, last_edit), count and warnings.

read_map_chat read

The conversation of a shared map (SchemAgentic'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 SchemAgentic.

{ "map_id": "id_1730450000_9f2c", "limit": 20 }

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

list_map_changes read

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.

{ "map_id": "id_1730450000_9f2c", "since": "2026-11-05T08:00:00Z" }

The structured result has 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

The saved versions of one map (SchemAgentic's Version History), 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.

{ "map_id": "id_1730450000_9f2c" }

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

read_map_version read

One saved version (a version_id from list_map_versions), read 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, 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 the next SchemAgentic update with the switch 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 is 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.

{ "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). The structured result has 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 SchemAgentic 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 SchemAgentic brings the nodes back but not that look; the kept version has both. Unapproved, it lapses after 14 days. It needs the next SchemAgentic update; older apps 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 map that agents or services run on (turn them off first: a request never stops them); 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.

{ "map_id": "id_1730450000_9f2c", "version_id": "v1793698800_k3x9q2", "reason": "Today's edits dropped the budget branch." }

The structured result has 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

Exports one map from the copy your SchemAgentic 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 SchemAgentic 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 is 2 requests, and one more for every 50,000 characters past the first 50,000.

{ "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. The structured result has 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

Lists the dated nodes (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 SchemAgentic 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>@schemagentic.web.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 SchemAgentic 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 is 5 requests, and one more for every 50 maps and sharing records read past the first 50; for one map, 2. A SchemAgentic link in a title reads (a link to a map).

{ "format": "ics", "from": "2026-11-01", "to": "2026-12-31" }

The reply starts Dates in the user's 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. The structured result has format, map_id (for one map), events (map_id, map_title, node, item, title, its day for an all-day event, or start and end, all_day), counts (all_day, timed, partial_dates, unkeyed, maps_read, maps_with_dates), text, offset, next_offset and warnings.

get_node_content read

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. A call is 1 request, and one more for every 50 maps and sharing records read past the first 50. It answers only while hiding maps from agents works on the server.

{ "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. The structured result has map_id, title, revision, node (id, eid, title), items (index, kind, and what each kind holds), rich, hidden_links and warnings.

get_map_links read

Lists the maps one map links to (its map-link cards and SchemAgentic links) and the maps that link to it — or, without map_id, every link between your maps, 500 a page — from the copies your SchemAgentic 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 is 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.

{ "map_id": "id_1730450000_9f2c" }

The structured result has 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

Returns the small picture of one map your SchemAgentic 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 is 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).

{ "map_id": "id_1730450000_9f2c" }

The reply: Thumbnail of "Launch plan" (<w> × <h>, <n> KB, published <day and time> UTC). and the picture as an MCP image block (image/jpeg). The structured result has 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 SchemAgentic, 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 the next SchemAgentic update; older apps 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).

{ "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" ] ] }

The structured result has 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 older SchemAgentic cannot show waits until it lapses. Once approved and applied, get_command_status says so (code table_changed).

{ "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. The structured result has 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 SchemAgentic 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 SchemAgentic runs there with the switch on, from the map as last saved (your unsaved changes are not in it), and saves it as a new file in SchemAgentic's exports folder there — Documents/SchemAgentic Exports on Windows and Linux, SchemAgentic/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 SchemAgentic's map lists: open it from that folder. It never goes to SchemAgentic Cloud or iCloud, 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). A map's agents' run records, services, approvals and ports are never in it. 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 SchemAgentic), as are maps you hid from agents and encrypted maps. It lapses after 7 days, and a call is 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 the next SchemAgentic update; older apps never get it. Once done, get_command_status says exported, with the size (see What an export ended with).

{ "map_id": "id_1730450000_9f2c", "format": "docx" }

The structured result has 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 the switch on. A device with that drive does it the next time SchemAgentic runs there with the switch on, one map at a time, at least 2 seconds apart, 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 is 10 requests.

Refused, and nothing queued, past the day's 5 and while another copy request waits. It needs the next SchemAgentic update; older apps 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.

{ "drive": "cloud", "folder": "Projects" }

The structured result has command_id, status (pending), expires_at and warnings.

find_in_maps read

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 is 10 requests (and, on accounts with limits, more 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).

{ "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

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 SchemAgentic 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 SchemAgentic, or because the map holds more items than the copy can carry — open the map once in the next SchemAgentic update with the switch 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).

{ "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 SchemAgentic 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. SchemAgentic 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 SchemAgentic update, device_update_needed. While you have review on, it also warns needs_review. Once applied, get_command_status says so.

{ "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 SchemAgentic 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).

{ "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 SchemAgentic 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.

{ "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 SchemAgentic 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.

{ "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 SchemAgentic 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.

{ "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[].

Search and fetch (ChatGPT connections)

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.

search read

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 search counts as 5 calls, 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

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.

Map view and prompts (chat apps)

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

Shows one of your maps as an interactive, read-only picture in the chat: its topics as an outline (or a tree) you can fold, pan and zoom, with a topic's note on a tap. It is drawn from the copy your SchemAgentic app published, as read_map reads it, and shows text only — no pictures, files or links from the map, and nothing of its agents' runs, services, approvals or ports. It opens as an outline, because the copy holds no positions and a tree would misdraw a schema. A large map shows its first 2,000 topics; read_map reads the rest. Nothing changes: the edit tools change the map. A call of it is 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).
• 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 SchemAgentic, 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 the outline and a tree, or to full screen. It follows the chat's light or dark theme. Once map links are switched on, Open in SchemAgentic 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 (outline), 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__schemagentic__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>.

How writes work

The request is carried out by your app, signed in to the same account with the switch on:

• create_map — the next time SchemAgentic starts, or you sign in; from the next SchemAgentic update also while the app is running (see Live delivery). The new map lands in your file list like any other.
• add_nodes and set_background — the next time you open that map, or, from the next SchemAgentic update, at once while it is open (see Live delivery). From the next SchemAgentic update, a map open view-only waits until you switch to editing.
• insert_nodes, update_nodes and move_nodes — the same way, by the next SchemAgentic update only, all of a request or none of it (see Editing nodes).
• add_content — the same way, by the next SchemAgentic update 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 — the same way, by the next SchemAgentic update 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 — the same way, by the next SchemAgentic update 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 — the same way, by the next SchemAgentic update 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 the next SchemAgentic update, 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 says what changed, and a new map from create_map appears in your file list without a restart. It works while you are signed in with the switch 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 the next SchemAgentic update each request is one step in the map's undo history, formatting, folding and copies included (a focus is no step): Undo takes back one request at a time. 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 everything applied since the banner appeared, and OK. It stays until you choose one, change the map yourself, or leave it.
• 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 the next SchemAgentic update only, by one device that has the file (or the drive) and the switch on, while the app 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 the switch 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 theme or scene in it is left off where your plan does not include it (the result counts them, gated).
• Nothing is ever replaced. No agent request, and from the next SchemAgentic update 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: SchemAgentic 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 SchemAgentic on the device that trashed it.
• Copies get their own ids. duplicate_map, and from the next SchemAgentic update 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 the next SchemAgentic update. SchemAgentic 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 SchemAgentic 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, on one whose agents or services can run, 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.
• Tables, exports and copies. edit_table is applied as the edit tools are, by the next SchemAgentic update 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 SchemAgentic update only, when the map is open, as one change you can undo, all of a request or none of it; older apps 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 SchemAgentic 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 SchemAgentic 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, 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 SchemAgentic 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.

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; renames, restyles, formatting, ticks and moves 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 SchemAgentic applies only after you approve each one. No request deletes or replaces a file or a folder: 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). propose_table_edit only asks too: a table cell that has text is changed or cleared, a table retitled, or a row or a column removed, only when you approve it.

Until then the change does not exist, and read_map will not show it. This is deliberate. Your maps are files with a format the app owns; letting a server rewrite them behind the app's back is how documents get corrupted. Going through the app also means every change arrives through the normal editing path — it lands in your undo history, and you can reverse it like anything else you did yourself.

Files and folders: names, folders and drives

• Names. A file or folder name is 1 to 100 characters, trimmed; a file name given with SchemAgentic's extension (.schemagentic) loses it, and the file keeps its own. A name is refused with a control or text-direction character, any of / \ : * ? " < > |, a space or a dot at its start or end, as . or .., as a Windows device name (CON, PRN, AUX, NUL, CONIN$, CONOUT$, COM0 to COM9, LPT0 to LPT9, with or without an extension), when it shows nothing (only invisible characters), or with a broken character. Names are kept in Unicode's composed form (NFC), and two names that differ only in letter case are the same name.
• Folders. A path relative to the drive's files, folders separated by /, each a valid name, at most 10 folders and 240 characters; "" is the drive's root. A device never goes outside the drive's files, or into a trash.
• Drives. A request names one of these. A device that has not set a drive up, or is not signed in to it, leaves the request to another device; it never asks you to sign in. The Shared tab is never a source or a destination.

Tables

From the next SchemAgentic update an agent can read a table's cells (get_node_content, once rich content is on) and change the table in two ways:

• Adding, directly. edit_table fills cells and column headers that are empty, and adds rows at the bottom and columns at the right, applied when the map is open as one change you can undo. It never changes or clears a cell that has text, and never removes anything.
• Changing, with your approval. propose_table_edit asks you to change or clear cells and headers that have text, retitle the table, or remove rows or columns. Its card in the map's Agent Requests lists every change with the text before and after; Approve All never includes it.
• Bound to the table the agent read. Both carry the table's digest as the copy holds it: its title, its headers in their order, its row headers and every cell. If you sort the table, move a row or a column, or edit a cell, a header or the title before a fill applies, the request fails and nothing changes (target_changed); a request for your approval then offers Reject only. New rows alone are added whatever happened. So an agent needs the whole table in the copy for every change but new rows: a table cut short in a large map's copy (cells_cut) is changed in SchemAgentic, not by an agent.
• Text cells only. A cell that holds a picture, a check box or other content is not changed: the request fails (unsupported_cell), as does a change that would make the table larger than 100 rows, 20 columns or 2,000 cells (table_too_large). While you are editing the table, the request waits until you finish.
• One line of plain text. Line breaks, tabs, runs of spaces and the other Unicode spaces (such as the no-break, ideographic and zero-width no-break spaces) become one space, and control characters are dropped, so an agent cannot write them into a cell.
• Undo. One request is one step: Undo takes back all of it, and the table's own undo steps from before it are cleared.

Exports

An agent gets a map as a file in two ways:

• From the server, as text. read_map (JSON, Markdown, OPML, CSV, plain text) and export_map (FreeMind, a web page, a JSON tree, a formula-safe CSV) export the copy your app published, in pages the agent reads. Nothing is saved, and nothing is fetched: links that open your other maps are left out.
• From your app, as a file on your device. export_map_file asks a device that has the map to export it through SchemAgentic's own Export (Word with its pictures, SVG, Markdown, OPML or text), from the map as last saved and with the request's options, never your export settings. The file lands as a new file in SchemAgentic's exports folder on that device (Documents/SchemAgentic Exports on Windows and Linux, SchemAgentic/Exports in the Files app on iPhone and iPad), never over a file or folder that is there, and is not shown in SchemAgentic's map lists: open it from that folder. On an iPhone or an iPad the folder goes when the app is deleted. It never goes to a cloud drive: SchemAgentic Cloud and iCloud answer drive_unsupported, as do the Mac app (its sandbox would keep the folder hidden: it waits for a folder you pick), the Android app, the Windows Store app and the web app, and the file is never put somewhere else instead. Nothing of the file reaches our server or the agent: the agent learns the format, the size and, while file places are shared, where it went. A map's agents' run records, services, approvals and ports are never in an export.
• Limits. At most 20 export requests a day for your account, an export of at most 25 MiB, and at most 200 MiB of agents' exports a day on each device (both answer export_too_large, before anything is written); a map larger than the app exports for agents (at most 5,000 nodes) answers too_large. The formats follow your plan, as the Export menu does (gated).
• Never. A map shared with you by others (export it yourself in SchemAgentic), a map you hid from agents on that device, an encrypted map. The export never changes the map, and the app does it without showing anything; the map open with unsaved changes is exported as last saved, and the result says so (unsaved_changes).
• Copies of maps you have not opened. request_map_copies asks a device to publish, one at a time, the copies agents read of the maps in one folder that have none yet, as opening each with the switch on would; it never replaces another device's copy, skips hidden and encrypted maps, and the MCP Server dialog shows the last run.

From the next SchemAgentic update, every web page SchemAgentic exports, yours from the Export menu included, writes map text as text: a link card's label, a sound's name or a file name can no longer add markup or a script to the page, links other than http, https and mailto stay plain text, and a local video or sound path is no longer written into the page (a video that is not on the web is left out). The JSON export no longer writes the paths of pictures and sounds on your device either.

Deletes and replacements: Agent Requests

An agent cannot delete or replace anything in your maps by itself. propose_delete, propose_replace and revert_command only ask: the request waits on the server until you answer it in SchemAgentic, and post_suggestion leaves you a message. From the next SchemAgentic update:

• Where they show. A map with requests waiting shows Agent Requests with a count in its toolbar, and says An AI agent asks for your approval. when new ones arrive. Each request lists what it would change, named as the map names it now, with the agent's reason under The agent says:; Show highlights the nodes and links it would remove or change, without changing the map. A request that replaces notes shows the start of the new notes, and one that replaces an item's words shows those words as they are now and the new ones.
• Approve applies the request at once, as one change: Undo on its card, or the usual shortcut, brings it all back. You need the map open for editing, a connection to the server, and no edit of your own in progress: in view mode Approve and Undo wait until you switch to editing (Reject, Reject All and Dismiss still work), and while you are busy with the map Approve says on the card why it cannot go ahead yet. A request that no longer fits the map (the nodes it names are gone, or the map changed under it) says so, changes nothing, and can be dismissed. No banner follows an approval: you just chose it.
• Reject discards it; you can say why, and the agent reads your reason. Approve All approves the requests on show, one at a time, each as its own change; whenever they delete or replace anything (only adding items to a group does not) it asks first, with how many requests, changes and topics to delete, and a request that arrives meanwhile stays waiting. Reject All rejects the requests on show and stops an Approve All under way.
• Messages. A message an agent leaves shows as a card with its title and text; Mark as Read clears it. The MCP Server dialog lists what waits on every map: Open... takes you to a map's Agent Requests, Mark as Read... clears a message, and a request this version of SchemAgentic cannot show offers Reject....
• Your agents and services. If a topic a request deletes runs one of your agents or services, its card says so: the agent or service pauses until the topic comes back, and an Undo brings it back.
• Answered once. A request is decided once: approved or rejected on one device, it is decided on the others too. While the Agent Requests are open, an agent's other changes to that map wait until you close them.
• Lapses and limits. A request you do not answer lapses after 14 days, a message you do not read after 30. Up to 20 requests for your approval (10 for one map) and 20 unread messages wait at once, besides the agent's other requests.
• Undone by you. When you undo an agent's request in SchemAgentic (or redo it), the app tells the server, so get_command_status tells the agent (undone_by_user) instead of letting it believe its change is still there.
• Moving a map to the trash. A propose_trash_map request shows as a card that says the map goes to this device's trash, where you can recover it for 90 days, and that approving closes it. Approve it on a device that has the map (elsewhere the card says so): SchemAgentic closes the map if it is open there and moves its file to that device's trash. Approving is refused, and nothing changes, while the map is open on another of your devices with the switch on (close it there first), while you share it with others (stop sharing it first), or while any of its agents or services is turned on (turn them off first; approving never stops them). If the map cannot be closed on this device, nothing changes and the request keeps waiting.
• Restoring a version. A propose_restore_version request shows as its own card: the version's date, who saved it and its summary, what the app keeps first and what Undo will not bring back, and Show this version, which opens the version to look at, without restoring it. Approve All never includes one: approve it on its own card. Approving is refused, and nothing changes, for a map you share with others (restore it from Version History instead), while any of its agents or services is turned on, while the map is open on another of your devices with the switch on, and once the version is no longer kept (This version is no longer kept.). Where this device records no versions (not signed in, or no Version History) the card offers Reject only.
• Changing a table. A propose_table_edit request shows as its own card: the table's title and node, then every change it asks for — each cell or header with its text now and after, the new title, each row or column it removes, named by its header or its first cell — read from the table as it is when you look. Approve All never includes one. If the table changed since the agent read it, the card says The table changed since the agent asked for this. and offers Reject only; while you are editing the table, approving waits until you finish (The table is being edited. Finish editing it first.). An approved change is one step you can undo.
• Older apps never show requests for approval or messages: they wait and lapse. Nothing is deleted or replaced without your approval, whatever the app.

Review mode: approve every change first

From the next SchemAgentic update, the MCP Server dialog has a switch, Review every agent change before it applies, for your whole account. Once our server takes it, while it is on, every change an agent asks for to a map you already have — add_nodes, set_background, the edit, content, style, link and table tools, add_map_link and the five Phase 13 writes — waits in that map's Agent Requests as one card, An AI agent wants to make these changes, with a line for each change, until you approve or reject it.

• Only the latest app approves. You approve with the map open in the next SchemAgentic update (or later); it then applies the request exactly as it would have applied it directly, as one change you can undo. An older app shows Update the app to review this request. and offers only Reject. A request is never applied without your approval while review holds it.
• What it does not hold. New maps (create_map, build_map), file requests and the requests that already ask for your approval. Changes that were already waiting when you turned review on still apply directly: the switch says how many.
• For the agent. The tool answers as before and adds The user turned on review: this waits for their approval in the SchemAgentic app (request <id>). (and the warning needs_review); a reviewed request lapses after 14 days unanswered and counts among the 20 that may wait; under review add_nodes adds at most 300 nodes a call, under a node read_map shows. get_sync_status says whether review is on.
• If it is paused. Should we switch review off on our server, your switch stays as you set it, but changes apply directly and the dialog says Review is not available right now: agent changes apply directly.

Following a request

get_command_status and list_commands say where each request is:

A request for your approval is pending while it waits in Agent Requests, and can end one more way: rejected, when you reject it (the message says why, if you told the agent). A message is pending until you read it, then done. "Undone" is never a status: a request you undid in SchemAgentic stays done, and get_command_status warns undone_by_user. A file request is pending while it waits for a device that has the file, or for the map to be closed; build_map's and duplicate_map's status gives the new map's id once it is done; and a file request no device can do expires 48 hours after the last recent device said so.

Limits and timing

• Lifetimes. A create_map, add_nodes or edit not applied within 30 days lapses, including one queued before this rule (30 days after it was queued); a set_background lapses after 7 days; a request for your approval lapses after 14 days, and a message unread after 30. Finished requests are deleted 30 days after they finish. A file request lapses after 7 days, and a build_map after 30.
• At most 20 requests can wait at once. Past that, a write is refused with Too many pending commands. — open the app to let them through, or withdraw some with cancel_command. File requests count among them.
• Requests for your approval and messages count apart. Up to 20 requests for your approval (10 for one map) and 20 unread messages wait at once, besides the others; past that, the tool is refused with Too many proposals are waiting for the user's review or Too many unread messages are waiting for the user.
• One device builds a new map. The device that picks up a create_map holds it for 10 minutes, so another device starting at the same time does not build it again; if the first never reports back, another can build it after that. The next SchemAgentic update also holds a map's requests while it applies them and never applies one twice; until it is on every device, two devices opening the same map at the same moment can both apply an add_nodes.
• Outlines can be up to 256 KB, and so can the changes one edit call queues. One call takes up to 300 nodes (insert_nodes), 200 changes (update_nodes) or 100 moves (move_nodes); a title up to 1,000 characters and a note up to 10,000. One connect_nodes call takes up to 100 new links and 100 line changes, with up to 4 animations a line; one format_nodes call up to 200 changes with up to 20 spans each; one set_node_state call up to 200 check items and 100 folding items; one copy_nodes call up to 50 copies of 2,000 nodes in all; one refine_map_style call up to 50 spacing and 50 restyle items. One propose_delete call takes up to 100 nodes, links, labels, lines or content items of each kind, and one propose_replace call up to 50 notes (10,000 characters each), 50 lines with 4 animations each, 100 item texts (500 characters each) and 50 groups with 20 new items each; 400 changes in all.
• list_files gives 100 maps a page and reads the 2,000 most recently saved maps; text sent to build_map is at most 256 KiB and 5,000 nodes (20 central topics, 30 levels), and the request it queues at most 300 KiB; a file or folder name is 1 to 100 characters, a folder path at most 10 folders and 240 characters (see Names). A map an approved request moved to the trash can be recovered for 90 days, on the device that trashed it.
• list_shared_maps gives 50 maps a page and looks through the first 1,000 shares you are in; read_map_chat 20 messages a page by default, at most 30, each cut at 500 characters; list_map_changes 100 nodes and 100 links a page, at most 30 days back; list_map_versions the newest 100 versions; read_map_version reads a version up to 16 MiB, its text outline cut at 256 KiB as read_map cuts the current copy, and compare_to lists up to 200 nodes of each kind. A request to restore a version lapses unapproved after 14 days.
• export_map and export_events give pages of whole nodes or events, at most 45,000 characters a reply by default (max_chars 1,000 to 150,000, the reply's text and its data together; a web page's own head takes about 1,100 of them), export_events up to 500 events a page, looking through the 200 maps saved most recently and reading 25 of them in full; get_node_content reads a node's 20 content items, a table up to 100 rows, 20 columns and 2,000 cells; get_map_links 100 links each way for one map, or the links among your first 2,000 maps, 500 a page; a picture is at most 48 KiB and 256 pixels a side. One edit_table call fills up to 200 cells and 20 headers and adds up to 50 rows and 20 columns, and one propose_table_edit call changes up to 50 cells and headers and removes up to 50 rows and 19 columns, for a table of 1 to 100 rows and 1 to 20 columns with at most 2,000 cells after the change; a cell's text is up to 500 characters, a header's and the title up to 200. At most 20 export_map_file and 5 request_map_copies requests a day (UTC); an export is at most 25 MiB, each device saves at most 200 MiB of agents' exports a day, and a copy request publishes up to 50 maps.

Refused, not queued

• A map someone else shared with you is read-only for agents, even when you can edit it: a write is refused (sharing is read-only for agents), and requests queued for it earlier are refused when it is opened. Your own shared maps stay writable.
• A map hidden from agents (Visible to MCP Agents off) is answered as no map at all (No map with map_id …), and its waiting requests are refused.
• An encrypted map (from the next SchemAgentic update): its waiting requests are refused with the map is encrypted.
• A stale read: a revision from before the map was last saved is refused. So is a node the edit tools cannot name for certain, a central topic to move, or a move into the node's own branch; the edit tools' refusals end Nothing was queued.
• Files. Maps someone else shared with you are never renamed, moved, copied or trashed by an agent (duplicate_map names Save As); a map you share with others, or one whose agents or services are not all turned off, cannot be trashed by a request; a folder that holds a map you hid from agents or encrypted cannot be renamed; and a name that is not valid (see Names) is refused before anything is queued.
• Sharing and versions. The seven sharing and version tools answer only for maps your app published. The four share tools give a map that is not shared with you, one you or its owner hid, and one you are no longer in the same answer (No shared map with map_id "…" that this user can see.); the version tools answer No map with map_id "…". Use list_maps first. for a map you or its owner hid. Sharing is read-only to agents. A restore is refused for a map you share with others, for maps others share with you, and for a map whose agents or services can run. A map whose owner hid it from agents is answered as if it did not exist by every tool, the read, write and file tools included.
• Exports, tables and pictures. Every tool from export_map on answers No map with map_id "…". Use list_maps first. for a map you or its owner hid, as for one not published. edit_table and propose_table_edit are refused for maps others share with you, as the other edit tools are, and export_map_file too (export them yourself in SchemAgentic).

Notes and warnings

A write's reply can end with Note: … sentences, and clients that take structured output get the same as warnings, each with a code:

Why a request failed

From the next SchemAgentic update, a failed request carries a code in its result:

A request the app had already applied is reported done, never applied twice; so is an edit that found everything already as asked (ops_applied 0). A request you reject is rejected, never failed.

The server tells what your devices can do from what each app reports when it picks up requests (see below). Until an app has done so, it makes no such claim.

What a file request ended with

From the next SchemAgentic update, a file request (and a propose_trash_map you approved) ends with one of these codes in its result:

Every failure changes nothing, but old_kept. A device that cannot do a file request just now (the file or drive is not there, the map is open, a cloud list is still loading) hands it back for later, or for another device: that never fails it.

What a restore ended with

From the next SchemAgentic update, a propose_restore_version you approved ends with one of these codes in its result:

A restore also fails with not_owner, encrypted, excluded or bad_command, as a request does. A device that cannot restore just now (the map is busy, the sharing list is still loading, keeping the current map failed) hands the request back to wait: that never fails it.

What a table request ended with

From the next SchemAgentic update, a table request ends with one of these codes in its result:

What an export or a copy request ended with

From the next SchemAgentic update, an export or a copy request ends with one of these codes in its result: